This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When I call simultaneously SharedClassObject.findObject from two threads (main and AWT) for IDESettings class I receive the same instance of IDESettings but setting uiMode has incorrect default value 1 instead of 2 which is deserialized by first call of findObject. This behaviour cause annoing trouble in winsys so please take care about it. I can help with reproduction. Steps to reproduce: Take any dev build from Tuesday last week (9 Apr 2002) or later. First call of findObject is from Main.initializeMainWindow second from UIModeManager.getUIMode. The problem is that instance of IDESettings from second call still returns incorrect value of setting uiMode. I suspect synchronization in findObject should be improved not to return instance before settings are completely deserialized.
My commit from 8 Apr is causing that second early call of findObject for IDESettings. As workaround I will try to avoid it but anyway problem with findObject remains.
David, please take care of this issue. Thanks
this is causing bug 22227 - "The Welcome screen is always shown"
while trying to fix #22451 I noticed Jesse's comments from the fix for #17711 // #17711: folder lookup not yet initialized. Try to load the option later. // In the meantime the default state of the option will be available. // If any attempt is made to change the option, _and_ it is later loaded, // then we print a stack trace of the mutation for debugging (since the mutations // would get clobbered by loading the settings from layer or whatever). The above comment and SharedClassObject.findObject(x, true) implementation allows returning an object which is actively being modified and whose getter methods return default values because the values are being extracted from disk. My question is whether it makes some sense to try to change it or whether the current impl. is ok? I mean to change the behaviour to block in a second thread before returning the value and wait for the first thread to finish loading of the SystemOption? And is the proposed solution safe? Or better to leave the code there as it is now? Any suggestions?
Please read carefully my last comment in issue #17711. A call to SCO.findObject *after* lookup is ready should block and give you the prepared object. If you try to use SCO.findObject *before* lookup is ready, and the object is in fact persisted in a .settings file, you will have serious problems - so don't ever do that. It is up to the caller to ensure that lookup is ready first. After that point, you should be safe.
Where does it block if created is false? Sorry but I don't understand the code in findObject - I cannot see the blocking call.
IMHO correct behavior of SCO is that findObject should only return an initialized object, if it is available from lookup. If this does not work currently, it is a bug in SCO - should be fixed and a test written. A pathologically written SystemOption (with some kind of cycle) might deadlock as a result, we will see.
Created attachment 5516 [details] patch - apply at your own risk! ;-))
I have tried to run all core/openide tests and don't see any problem. But adding these two lines to SCO.findObject // synchronizing on the same object as returned from getLock() synchronized (clazz.getName().intern()) { ... } does not sound like something we would like to do. But after trying to find something more clever (like trying to invent some waiting scheme instead of simple lock) I didn't find anything that would not be equivalent of the patch above. I propose either 1. apply the patch 2. mark the issue as WONTFIX Currently I am in favour of 2. I would like to hear from you what you think.
Waiting for your comments, suggestions. Thanks.
I vote for fix. If any problem would appear we can always revert fix back. I do not like current inconsistent behaviour of findObject().
I also vote for applying the patch. We know the current behavior is wrong. If the patch seems to be introducing some deadlocks etc., maybe it will have to be backed out, if there does not seem to be a clean solution - but that is still hypothetical. BTW David patches for review might better use the -b "ignore changes in whitespace" switch to cvs diff (in addition to -u or -c); would show much more clearly what you are doing.
Diff applied and created SharedClassObject 1.51.
*** Issue 15668 has been marked as a duplicate of this issue. ***
verified.