This is going to be an easy one to fix, but it did cause me to lose several hours.
The method WindowItem.getDockingWindowProperties() is not thread-safe. If two threads call it simultaneously on the same WindowItem, the two calls can potentially return two different objects, whereas the WindowItem always only contains a single DockingWindowProperties object at any time.
After spending several hours to try to work around that problem, I've noticed that it can't happen because the dockingWindowProperties is assigned in the constructor. If it were not assigned in the constructor, then the code would throw NullPointerExceptions when it access the member directly without going through the getter, as happens in many places in this class.
So the problem is that the test for null in getDockingWindowProperties() is misleading: The member can never be null. If it could, there would be a thread-safety issue and basically, the method would have to be synchronized.
Please remove the misleading check for null. It's unreachable code. Like so:
public DockingWindowProperties getDockingWindowProperties() {
return dockingWindowProperties;
}
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Yes, it looks like an unnecessary null check, but note that no IDW methods are thread-safe, all calls must be made from the AWT event thread so it's not really a bug.