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.
I cannot install the Netbeans-5.5 Enterprise Pack Preview on FreeBSD 6-STABLE. Downloading and installing the Linux distribution of the Netbeans-5.5 IDE Beta itself went smoothly (as it usually does with Linux packages on FreeBSD). But the Enterprise Pack preview refuses to accept that the Diablo Java VM available at http://www.freebsdfoundation.org/downloads/java.shtml with a version string output of freebsd$ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b00) Java HotSpot(TM) Client VM (build diablo-1.5.0_06-b00, mixed mode) is a "JDK 1.5.0 Update 1.0 or newer" Java VM. I think the version parsing information in the installer is a bit confused, but I can't seem to find a way to bypass it. The same problem occurs with a locally built 1.5.0 from SCSL source through the FreeeBSD ports mechanism.
nbusers mailing list thread news://news.gmane.org:119/e4hoq3$iek$1@sea.gmane.org
Installer should fetch the version no from the "java version ..." string, but from the VM identification string.
I changed the command we're running to fetch the java version from "java -version" to "java -fullversion". If diablo does not react properly to this, then a fix needs to be applied to it instead.
'java -fullversion' as of FreeBSD java/diablo-jdk-1.5.0.07.00 does not output a string that parses as the JDK update level. I would argue that this bug is not fixed, and that one should not rely on the output of 'java -WHATEVER' to verify the update level. The FreeBSD diablo JVM is a fully compliant JDK that has passed the Java certification processes necessary to be distributed as a binary release. NetBeans Enterprise pack is relying on non-standard behavior for your installer, and therefore orphaning a platform (FreeBSD) that has spent considerable volunteer time (and donations) to reach Java certification. What good is this certification if it is not respected by tool vendors? I know you can invoke the JVM from your installer. There is a perfectly good system property java.vm.version=diablo-1.5.0._07-b00 that can be inspected to verify the update level. You could also possibly put a switch in the installer to bypass this check.
Mark, How we can get this system property (java.vm.version) from the JDK? Let me explain. When we are checking if the pointed JDK is compatible, we invoke "java -fullversion" command on the pointed java and then parse the output. You offer us to get system property. In fact we don`t need SYSTEM property from the running installer.. but we really need this property from the certain JDK. So the possible solution is to make a small class that we would pass to the certain JDK for running and we`ll get java.vm.version property from [possibly] output from this class. We will discuss with Kirill Sorokin this possibility. As for the switch in the installer it seems that it would be hard to implement this: we can`t make our own switches for the installer, we can use only InstallShield standart ones. Btw, what output does "java -fullversion" command produce? Is it "diablo-jdk-1.5.0.07.00" ?
The output from "java -fullversion" is elvis:~$ java -fullversion java full version "diablo-1.5.0-b00" One gets the system property in the standard way, by using the System.getProperty() interface. And yes, I am proposing that the installer iterate through all the JDKs that it discovers through its filesystem inspection process, invoking a class to query the System property. Attached is a quick implementation of such code. I would recommend that one implement the necessary try/catch handlers for the various runtime exceptions that could be produced from the java.util.regexp package before putting such code in production.
Created attachment 32824 [details] Query java.vm.version System property for Update compliance level
Will be implemented for Ent.Pack 5.5 FCS. Too late for Beta, sorry :(
I've changed the installer behavior to use the value a the java.vm.version system property. Please verify once the daily builds become available. Note: The fix WILL NOT BE present in Ent. Pack Beta