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.
This bug was originally marked as duplicate of bug 268222, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE Dev (Build 201609290002) VM: Java HotSpot(TM) 64-Bit Server VM, 25.102-b14, Java(TM) SE Runtime Environment, 1.8.0_102-b14 OS: Windows 7 User Comments: stefan79: Tried to open the property-Window at a Web-project. ytn01: I installed FCS build. Started it,.. and upon prompt, imported settings from an existing NB 8.1 installation. (IDE started indexing Maven repostiories in the background) Then, manually registered a Tomcat 8.0.36 installation I have. Then, updated the Java DB configuration to point to a custom installation that I have. Then switched to the projects window from Services window,.. and RIGHT CLICKED on a Java Web Project that was opened from last session. and Exception got thrown. The RIGHT CLICK seems to be the triggering cause. Rahul.khandelwal: Error happens when I right click on project and select project properties. I can't even change properties of my project because of this issue. cezariusz: . cezariusz: Web project properties ytn01: I installed FCS build. Started it,.. and upon prompt, imported settings from an existing NB 8.1 installation. (IDE started indexing Maven repostiories in the background) Then, manually registered a Tomcat 8.0.36 installation I have. Then, updated the Java DB configuration to point to a custom installation that I have. Then switched to the projects window from Services window,.. and Exception got thrown. cezariusz: Right click on a web project. Stacktrace: java.lang.NullPointerException at org.netbeans.modules.java.api.common.ui.PlatformUiSupport$PlatformComboBoxModel.getPlatformNames(PlatformUiSupport.java:793) at org.netbeans.modules.java.api.common.ui.PlatformUiSupport$PlatformComboBoxModel.getSelectedItem(PlatformUiSupport.java:754) at org.netbeans.modules.java.api.common.ui.PlatformUiSupport$SourceLevelComboBoxModel.<init>(PlatformUiSupport.java:917) at org.netbeans.modules.java.api.common.ui.PlatformUiSupport.createSourceLevelComboBoxModel(PlatformUiSupport.java:492) at org.netbeans.modules.web.project.ui.customizer.WebProjectProperties.init(WebProjectProperties.java:410) at org.netbeans.modules.web.project.ui.customizer.WebProjectProperties.<init>(WebProjectProperties.java:360)
Created attachment 162281 [details] stacktrace
Duplicate of fixed issue #268222. The PlatformUiSupport.java:793 which should cause the NPE is now the null check as seen: http://hg.netbeans.org/releases/file/5fd841261bf9/java.api.common/src/org/netbeans/modules/java/api/common/ui/PlatformUiSupport.java#l793 *** This bug has been marked as a duplicate of bug 268222 ***
@Tomas, I got this error for 29th September build. I will check for the solution in 30th September build.
Still getting this issue in nightly build *201609300002*.
I've looked into the main-silver repository (the repository nightly builds are created from) and the patch is there as well http://hg.netbeans.org/main-silver/file/ecbe2a0fb8f4/java.api.common/src/org/netbeans/modules/java/api/common/ui/PlatformUiSupport.java#l793. I am going to verify if it was a part of the nightly build.
The fix is included in the night build: 201609300002. The affected line contains the null check which cannot throw NPE. There may be some updated version of module in user dir overriding the module from build 201609300002.
Yes, it's the case. Looking at the messages.log the org.netbeans.modules.java.api.common module is significantly older than the other modules. Important lines from the log: .... org.netbeans.libs.antlr3.runtime [1.22.0.1 1 201609300002] org.netbeans.modules.java.api.common/0 [1.82 nbms-and-javadoc-610-on-20160921] org.netbeans.libs.json_simple/1 [0.13 201609300002] .... As you see modules org.netbeans.libs.antlr3.runtime and org.netbeans.libs.json_simple are from the 201609300002 build but the org.netbeans.modules.java.api.common module is older nbms-and-javadoc-610-on-20160921 (09/21), probably from autoupdate in userdir. To resolve the problem please delete the user dir or start the ide with a new one (--userdir)
(In reply to Tomas Zezula from comment #7) > the org.netbeans.modules.java.api.common module > is significantly older than the other modules. > [...] > probably from autoupdate in userdir Shouldn't be the modules from the userdir automatically disabled (ignored) when a newer ones are in the base application? This can lead to a whole host of problems.
Yes, it disables the module when the installed module version is higher compared to installed one. The module version is increased in case of API change. The fix does not contain any api change, so both installed nad new module are "compatible". However the installed module is buggy. The builder does not increase module version.
(In reply to Tomas Zezula from comment #9) > The module version is increased in case of API change. So you don't have something like a runtime version, which changes after each modification to the code (regardless of API change)? Actually why not to set the module runtime version to the build number, the same as for the whole IDE?
Oh, now I see there is a module build number (I assume it's the second part of [0.13 201609300002]). But it isn't used when disabling older modules from the userdir?
>Oh, now I see there is a module build number (I assume it's the second part of [0.13 201609300002]). Yes, it's the second number. >But it isn't used when disabling older modules from the userdir? As far as I know only the spec version (the first number) is used. If the module has the same spec version it is API compatible. Unfortunately I don't know details why it was decided in this way. Adding Jarda on cc.
*** Bug 268288 has been marked as a duplicate of this bug. ***