On 7/26/17 12:34 PM, Jim Graham wrote:
I'll do a search and see if there are any cases of the above paradigm left...
I did a basic grep over the Java sources in java.desktop looking primarily for synchronizations on a class, ignoring
synchronized methods (both instance and static) and synchronizations on an object other than a class (such as "this" or
"getTreeLock()").
I didn't find any cases of initializing a singleton without all of the tests inside the synch block (such as Toolkit
which does do the lazy initialization, but it has all of the lazy tests inside the synch block so it can't have
unordered initialization, but it might benefit from an inner class treatment for performance). Either I was imagining
it, or we've gradually cleaned up a lot of those in the past.
I did find the following related issues:
TrayIcon.setPopupMenu()
- synchronizes on TrayIcon.class, but then relies on tests from outside the synch block for correctness I believe -
the "already set" test should probably be duplicated inside the synchronization
I found a number of cases of "synchronized (Foo.class)" inside Foo.java, and some of them were the first statement in
the method - which begs the question of why the method wasn't just made synchronized in the first place.
Window.getWindows() and Window.removeWindowFromList() for examples...
...jim
