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.
[FFJ 3.0 CE; Sun JDK 1.4.0 beta 2; MDI] Problem occurs when auto-updating Java and ObjectBrowser modules at the same time on Win2k. The .nbms can be found at /net/honza-sun/export/share or Transfer/jzajicek/JP3 Steps to reproduce: 1. Start FFJ 3.0 CE (010817) on JDK 1.4 beta 2 with a clean userdir 2. Go to Project | Settings... | Java Sources and check the Default Compiler and Default Executor properties -- both should be set to External Compiler/Executor. 3. Auto-update Java and ObjectBrowser modules from the .nbms (see above) 4. After restarting, check the Default Compiler/Executor Settings again -- now they're set to Indirect Ant Compiler and Ant Executor 5. Note that existing Java nodes' properties depending on the default compiler/executor still show and use External Compiler/Executor 6. Try to create a new Java main class -- the properties are set to External C/E again 7. Try to change the Default Compiler/Executor in the Java Sources project settings -- the change is not propagated to the Java nodes properties 8. Restart the IDE, now the Java nodes' properties depending on the default compiler/executor show the same (incorrect) values as the Java Sources project settings We were not able to reproduce the problem on Solaris or Linux. This may be related to bugs #15586 and #15599. I'm attaching the ide.log file. The IDE was run with the -J- Dorg.netbeans.core.modules=0 and -J-Dnetbeans.debug.excetptions=true options.
Created attachment 2603 [details] ide.log
You can check if the suggested patch for #15599 in fact fixes this, though I would doubt it. Anyway: - this looks to me like a services bug, not module system, unless someone can specifically point to something the module system is doing wrong; I know little about how services and projects work, esp. in release32, pls. assign to someone who understands these things - I use Linux, if I cannot reproduce on it then I will have a hard time fixing anything
I tried to reproduce this but I did not observe this behaviour. I followed the reproduction steps exactly couple of times, but was unsuccessful. Could there be something I am doing wrong ?
I am able to reproduce the problem on my W2K machine using jchalupa's instructions. We can start debugging at the method org.netbeans.modules.java.settings.JavaSettings.setDefaultCompilerType() When the user asks for the default compiler type for "Java Sources" JavaSettings queries Services for JavaExternalCompilerType.class. Services returns null. This is the problem I added debugging statements to dump all services. There I see in the list a registered JavaExternalCompilerType.class. BUT this class has a different class loader than the one of JavaExternalCompilerType.class used for the query. Hypothesis: the JavaExternalCompilerType.class, which is registered to Services, has the wrong class loader. This puts the module installer back into suspicion.
Thanks Trung for the investigation--yes if the classloaders do not match then it is indeed a module system problem. In fact it is quite possibly a duplicate of #15599--has anyone checked this? It is possible the old java.jar is loaded into the system class loader, then the new java.jar is added as well, and somehow both class loaders are used--one by projects loading services, one by whatever loads the settings from manifest--though I am not sure how this could actually happen, it is just a guess. Someone able to reproduce, please check if the patch for #15599 fixes this as well. Even if not, please check the logfile with full logging on and the patch for #15599 applied and see if "#15599" is mentioned in the logfile on an "[org.netbeans.core.modules]" line (as it will be if the fix for that bug is activated). Again, if the problem cannot be reproduced on Linux then I cannot debug it very effectively--I have a Windows installation but it is barely set up. Also I do not have the mentioned JDK beta and cannot easily get it, so if it is dependent on that exact VM I will not be able to reproduce it. I have the java.nbm and can get the objectbrowser.nbm if necessary.
I was not able to reproduce the problem with the patch for #15599, so I'm marking this as a duplicate, although we'll need to run more tests to be absolutely sure. Jesse, thanks for your help. BTW, do you have an idea why it was reproducable on Windows and not on Solaris and Linux? Could there be any timing problem? *** This issue has been marked as a duplicate of 15599 ***
With #15599 patch I could not reproduce the prolem. Without it I can reproduce in 100% of cases on my W2K machine. Consider this fixed. It's not necessary a timing problem. The order in which modules are installed can have impact. We sort modules partially on dependency but otherwise the order is unpredictable (or JVM dependent)
Trung is right about the order--in #15999, the problem only occurs if you have the bad luck to start opening some dependent modules before you notice that there is an upgrade for the base module. So this could happen sometimes or not. Whether or not it happens would depend on how internal objects are hashed, which should probably not depend on timing but may well depend on VM and details of its memory model.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.