Random code cleanup tasks

Here is a list of code quality improvements/checks that I had in my todo list. I’ve purposely kept them in one issue because we have a lot of issues already. Feel free to add to this or provide feedback.

• Verify that calls to addListener have a corresponding removeListener

• Replace Exceptions.printStackTrace traces with java.util.logger

• Replace numbers with constants that call Insets method and perhaps make them available in a utility class so others can

• Review methods and arguement naming conventions in StringUtilities - having String string may be undesirable

• Make a utility class to display DialogDisplayer errors instead of doing this for example:

final NotifyDescriptor nd = new NotifyDescriptor.Message("The provided URL is invalid.", NotifyDescriptor.ERROR_MESSAGE);
DialogDisplayer.getDefault().notify(nd);

• Use StringUtils.isBlank() instead of the following:

!= null && !.isEmpty() everywhere.
isEmptyOrNull()

• Search replace “,” with SeperatorConstants.COMMA etc. Annotate @nothreadsafe methods - Not currently looking to pursue this throughout the whole codebase - new PRs can try to stick to this style if it helps dev. Integrate JSR-305 ~~* use @notnull etc ~~ SonarQube suggestions - Removed from list as this is covered in other Sonar related tickets.

[arcturus2]

Verify that calls to addListener have a corresponding removeListener

I’m interested in the benefit of this. I had a quick google as I was curious as to java best practices, and found the following link which leads me to believe it isn’t a garbage collection related code cleanup. https://coderanch.com/t/344003/java/call-remove-Listeners

Is it for another reason?

@aldebaran30701 actually my motivation was GC/memory/performance related. If I do a search for addListener in the code base I get 179 results and removeListener has just 25 occurrences. I’m uneasy about those numbers. Following on from memory cleanup work a while back, I noticed that if I closed a view like the Attribute Editor, not all of the memory it has been using is released, even if you wait for GC to do it’s thing. I’d like to explore the idea of removing Listeners when the views are closed and see if that helps.

Noted that the memory myth looks busted in their example but our code base in way more complicated and my thought is that we can help Java a bit my removing listeners when we don’t need them. I could be wrong though because I’m not an expert on this topic.

[github-actions[bot]]

This issue is stale because it has been open for 6 months with no activity. Consider reviewing and taking an action on this issue.