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.
There is a problem with JavaHelp on Solaris 9 when the IDE is run using the default J2SE 1.4 installation (the one that ships with Solaris 9). For some reason, javahelp packages are pre-installed in the default J2SE installation under the /usr/j2se/opt/javahelp directory. In addition, the following symlink is set in /usr/j2se/jre/lib/ext: lrwxrwxrwx 1 root root 35 Mar 11 18:50 jhall.jar -> ../../../opt/javahelp/lib/jhall.jar This all means that the pre-installed version of javahelp gets into the JVM's bootclasspath when the IDE is started. This version is incompatible with the version that ships with NetBeans. As a result, the Help system doesn't work at all. There is probably no simple way to fix this problem in NetBeans. Possible workarounds are: 1. Delete the symlink. 2. Install a separate JDK and don't depend on the default one. (1) may be dangerous as it's not clear which Solaris packages (if any) depend on the symlink.
There's nothing to be done in the NetBeans code. Marking as WONTFIX.
Re. the "incompatibility": even if the Solaris version of jhall.jar in fact matches the NB one (which is unlikely), it seems that something about the way in which it is installed (perhaps the use of a symlink rather than copy?) causes security exceptions to be thrown in NB. I suspect this would be true of *any* Java app using jhall.jar and installing a normal security manager, in which case there is a bug in the Solaris package, but this is only a guess. Workaround #1 *might* in fact be safe but we have not done the research on it. #2 is safe. A workaround in NB launcher code is a possibility but would require a nontrivial code change and is likely to be a hack specific to the details of the Solaris packaging scheme. A *possible* workaround for the user might be to delete the symlink but replace it with jh.jar from the NetBeans installation (a copy, not a link), so as to permit both NB and (hopefully) other unidentified Solaris packages to work unchanged. It may be worth an experiment.
Re-opening. Jesse and I brainstormed and we have a possible work-around: Prepend a copy of the NB/FFJ JavaHelp to the bootclasspath. This means the NB/FFJ copy is used (good) and we can add the appropriate entry to the security information.
Created attachment 5475 [details] Proposed patch
QA, please try out the attached patch on different machine configs: Solaris w/ default Java install (seems to work for me); Solaris w/ default Java install but using a different one; Solaris w/o JavaHelp installed; other Unices such as Linux. Intended behavior: if and only if the JavaHelp package for Solaris is installed, and it has installed the jhall.jar symlink, then NB's own copy of jh.jar is prepended to the boot classpath, overriding jhall.jar. Note that any apps running inside NetBeans VM which use authoring tools present in jhall.jar *but not in jh.jar* would still run up against this problem. E.g. JH indexers, maybe. I don't know of any, except the Ant task <jhindexer> used during the NB/FFJ build process, so don't try to build NB inside itself on Solaris machines using the default JDK. If that turns out to be a problem, a combined patch that grants access permissions to the Solaris jhall.jar may be feasible. Confirmed that the jhall.jar on the test machine I was given is in fact 1.1.2_01, a rev behind NB's own 1.1.2_02, and thus missing accessibility support (if I recall correctly). So we do want to be overriding the Solaris-supplied jhall.jar for A11Y reasons anyway.
It seems that the problem is in fact the symlink - making a copy of the JAR causes the exception to disappear. NB's ide.policy file lists jre/lib/ext/ as trusted, but not opt/javahelp/lib/.
Without the patch there aren't enabled help menuitems and help is empty. I do not saw any security exceptions. With the patch the help seems to work fine. Tested on Solaris9 with default j2se and different jdk. Will be tested on Linux by Milan.
Ops strange. Looks like the patch corrected the CE, however I still see empty help contents in EE even with the patch.
Created attachment 5488 [details] log from EE when executed with -J-Dorg.netbeans.core.Help=0
Jan please attach this info to issue #22612 instead.
Patch seems to be OK on Linux RH 7.1 with JDK 1.4. The patch doesn't affect classpath on linux.
Looks like the problem with EE isn't connected to default j2se installation on Solaris - see issue #22612. Patch for the Solaris 9 issue can be considered as verified.
P3 -> P1. This is a showstopper for FFJ 4.0 on Solaris 9. "Fix" available and verified by QA. #22612 is not related to this issue.
In orion_fcs: Checking in runide.sh; /cvs/core/release/bin/runide.sh,v <-- runide.sh new revision: 1.23.4.1.4.1; previous revision: 1.23.4.1 done and trunk: Checking in runide.sh; /cvs/core/release/bin/runide.sh,v <-- runide.sh new revision: 1.28; previous revision: 1.27 done No need for a release note item, I think, with this patch in place: should be invisible to users.
Rolled back temporarily in orion_fcs & trunk; Solaris 8 does not seem to like the syntax: runide.sh: test: argument expected
Recommitted patch (trunk & orion_fcs), this time without the -L check. Linux wants -L and will not accept -h; Solaris 9 wants -L or -h; Solaris 8 does not understand -L. -e is weaker but does not work on Solaris 9 (in sh, though works in bash). -f does work in sh, but acc. to docs it may or may not work according to $PATH (for SunOS compat!). So skipping this half of the test which is not so critical.
verifying
Resolved for 3.4.x or earlier, no new info since then -> closing.