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.
Build: NetBeans IDE Dev (Build 200902090201) VM: Java HotSpot(TM) Client VM, 11.2-b01, Java(TM) SE Runtime Environment, 1.6.0_12-b04 OS: SunOS, 5.11, x86 User comments: STACKTRACE: (first 10 lines) java.lang.VerifyError: (class: javax/help/ModifiedSearchView, method: createNavigator signature: (Ljavax/help/HelpModel;)Ljava/awt/Component;) Incompatible argument to function at java.lang.Class.getDeclaredConstructors0(Class.java:0) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at javax.help.NavigatorView.create(NavigatorView.java:130) at javax.help.HelpSet$DefaultHelpSetFactory.processView(HelpSet.java:810) at javax.help.HelpSet$HelpSetParser.tagFound(HelpSet.java:1495) at com.sun.java.help.impl.Parser.tag(Parser.java:59) at com.sun.java.help.impl.DocumentParser.parseTag(DocumentParser.java:789) at com.sun.java.help.impl.DocumentParser.parse(DocumentParser.java:166)
Moving JH issues to Victor.
Raising to P2 per discussion on the nb tech council.
Petr, is there a pointer to the discussion summary ?
Usually a stupid bug is time consuming to find its cause, but the cause is very very simple. This bug is not exception... A cause is the distribution of the Solaris 10 includes the JavaHelp package, version 2.0 (but not required 2.0_05!), i.e /usr/jdk/packages/javax.help-2.0 . (I have not checked it for OpenSolaris, but it seem the same.) The jhall.jar from this package is attached (i.e. symlinked) as an extension of Java packages for the all JDKs/JREs distributed with the Solaris OS. Current implementation of the NetBeans includes a path to the jhall.jar file on the Solaris platform into the "Boot & Ext. Classpath". Hence, the javax.help.NavigatorView class from the jhall.jar is used instead of the expected class from the jh-2.0_05.jar that is distributed with the NetBeans. Note, a path to the jhall.jar file has been included in the "Boot & Ext. Classpath" even if I use a JDK version manually installed from jdk-6u12-solaris-i586.sh in my home directory. Conclusion: It is not an issue of the NetBeans Help System :-) Now, I see a couple of ways how to fix this bug: 1) We can filter out a path element containing the "jhall.jar" substring during generating of the "Boot & Ext. Classpath" at the start up of the NetBeans. Of course, a notification about such action should be logged immediately after a log message about of a value of the "Boot & Ext. Classpath" in the NetBeans log. 2) The NetBeans installer can upgrade JavaHelp version up to version 2.0_05 on the Solaris platform if a previous version of the JavaHelp has been installed on the system. Are there any ideas more?
No way for option 2: NetBeans installer should not upgrade _system_ libraries. Dealing carefully with classpath is the way to go. Any ideas except filtering out system jhall.jar at startup?
> Petr, is there a pointer to the discussion summary ? Sorry I can not find it now. But I think the reason was that this affects commit validation, and all platform-specific problems of the commit validation should be treated as P2s. CV must behave consistently across all platforms.
Jaroslav, could you please help with this issue it is not Help System issue, but it still NB issue what module(component/subcomponent) responsible for creating "Boot & Ext. Classpath "?
It seems adding -J-Djava.ext.dirs="" to the value of the netbeans_default_options in the etc/netbeans.conf might help to resolve this issue. But, AFAIK some modules of the NetBeans rely on the optional packages provided by Sun JDK/JRE, e.g. keni.ui module requires classes from jce.jar In any cases, a fix requires changing of the NetBeans configuration, and it is very dangerous change. So, I've changed target milestone to "next". Please, change it if I am wrong.
Sorry, please read -J-Djava.ext.dirs='' (not double quote marks!) in the previous post, because the the netbeans_default_options value is already enclosed in double quote marks.
Playing with java.ext.dirs would indeed be dangrous. But maybe you just want to tell the core.javahelp module to always loaded classes from its ext/javahelp2.jar instead of parent classloaders. That shall be possible by one manifest tag: http://bits.netbeans.org/dev/javadoc/org-openide-modules/apichanges.html#OpenIDE-Module-Hide-Classpath-Packages Using the "OpenIDE-Module-Hide-Classpath-Packages" tag shall solve issues with outdated versions of javahelp on solaris once and forever.
OIDE-M-H-C-P does indeed sound like the simple and correct way to solve this class of problem.
I absolutely agree, but OIDE-M-H-C-P magic doesn't work for me on both the Solaris 10 and Windows XP :-( I've change manifest.mf for the JavaHelp Integration module according to the document apichanges.html#OpenIDE-Module-Hide-Classpath-Packages: ---- ... OpenIDE-Module-Requires: org.openide.modules.InstalledFileLocator, org.openide.modules.ModuleFormat2 OpenIDE-Module-Hide-Classpath-Packages: javax.help.**, com.sun.java.help.** ... ---- AFAIU, in this case, the OIDE-M-H-C-P defines all packages that are declared in the jh-2.0_05.jar distributed with NB. A requirement for ModuleFormat2 was added to existing requirement for InstalledFileLocator. I've rebuilt the module and replaced org-netbeans-modules-javahelp.jar in the installation image of NB on the Solaris 10. But, there are no any effects. I see the VerificationError anyway. :-( Moreover, I see the following error on the Windows platform if (and only if!) the jhall.jar (2.0) is placed in the jdk1.6.0_07\jre\lib\ext\ directory: ------- java.lang.Error: Could not create engine named com.sun.java.help.search.DefaultSearchEngine for view: javax.help.SearchView@c60547 at javax.help.search.MergingSearchEngine.makeEngine(MergingSearchEngine.java:171) ... ------- It seems the optional packages from JRE have precedence of loading anyway. Do I have a mistake anywhere? BTW: I noticed that after compilation the manifest contains: OpenIDE-Module-Requires: org.openide.modules.InstalledFileLocator, org .openide.modules.ModuleFormat2, org.openide.modules.ModuleFormat1 Is it correct? In the project options dialog I see only InstalledFileLocator and ModuleFormat2 as the required tokens?
It should work, but I will try it on Linux to see if things get loaded from the right place.
In fact it _does_ work to ensure that loads from the javahelp module's ClassLoader go to the bundled jh.jar. However sometimes JH classes get loaded from the system class loader (i.e. Thread.CCL). HelpSetProcessor is directly responsible for doing so, and this can trivially be fixed, but there are also apparently inescapable loads from UIDefaults. Currently OIDE-M-H-C-P only affects the MCL on which it is declared, so when SCL is asked for a JH class, both the startup loader and the javahelp MCL are asked to load the same class, which causes ProxyClassLoader to report an ambiguous load and load neither, which causes some errors. I think I can change PCL to treat a load as unambiguous in case one of the putative parent loaders is a parent of the other. It works in case you reproduce using -J-Dnetbeans.classpath=.../jh-broken.jar (where jh-broken.jar is a copy of jh-*.jar with HelpSet.class corrupted), though so far does not seem to work when using -J-Xbootclasspath/a:.../jh-broken.jar; still investigating why. (Of course it does not help debugging that both UIDefaults and JH notoriously swallow all kinds of errors.)
Note that there used to be special logic in the launchers to exclude Solaris JH from the classpath, but this seems to have gotten deleted at some point. Anyway it would not help with commit validation. Fixed OIDE-M-H-C-P limitation in core-main #4c9fadfead1c, and using it in javahelp in core-main #0ea03eeef515.
Re. launcher logic - it needed to be deleted as any modification to bootcp disables "shared classes" in java. We are trying to avoid such modifications as much as possible (recent example of jaxws 2.1 could also be solved with bootcp tricks, but we rather invented and used the hide-packages support).
Integrated into 'main-golden', will be available in build *200903251400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4c9fadfead1c User: Jesse Glick <jglick@netbeans.org> Log: #159586 (prep): masked JRE/CP classes should not be accessible from SCL.