Cant seem to install on Linux

Post by **JustinVK** » Mon Jun 12, 2006 8:39 pm

I am confident that I have the java problems resolved, but I am getting a nullpointerexception early in the install process:

error log:

Exception:

java.lang.NullPointerException
at javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect (libgcj.so.7)
at javax.swing.plaf.basic.BasicTextUI$DocumentHandler.insertUpdate (libgcj.so
.7)
at javax.swing.text.AbstractDocument.fireInsertUpdate (libgcj.so.7)
at javax.swing.text.AbstractDocument.insertString (libgcj.so.7)
at javax.swing.text.PlainDocument.insertString (libgcj.so.7)
at javax.swing.text.AbstractDocument.replace (libgcj.so.7)
at javax.swing.text.JTextComponent.setText (libgcj.so.7)
at com.install4j.runtime.installer.frontend.BaseScreen.createTitleLabel (Unkn
own Source)
at com.install4j.runtime.installer.frontend.BaseScreen.setupComponent (Unknow
n Source)
at com.install4j.runtime.installer.frontend.BaseScreen.initScreen (Unknown So
urce)
at com.install4j.runtime.installer.frontend.screens.WelcomeScreen.<init> (Unk
nown Source)
at com.install4j.runtime.installer.frontend.InstallerWizard.setupScreens (Unk
nown Source)
at com.install4j.runtime.installer.frontend.InstallerWizard.<init> (Unknown S
ource)
at com.install4j.runtime.installer.Installer.initWizard (Unknown Source)
at com.install4j.runtime.installer.Installer.access$000 (Unknown Source)
at com.install4j.runtime.installer.Installer$1.run (Unknown Source)
at java.awt.event.InvocationEvent.dispatch (libgcj.so.7)
at java.awt.EventQueue.dispatchEvent (libgcj.so.7)
at java.awt.EventDispatchThread.run (libgcj.so.7)

System properties:

exe4j.moduleName=/home/snjvk/Desktop/XSLT/oxygen.sh
install4j.appDir=/home/snjvk/Desktop/XSLT
path.separator=:
java.vm.name=GNU libgcj
java.vm.specification.name=Java(tm) Virtual Machine Specification
java.runtime.version=1.4.2
java.home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
java.vm.specification.version=1.0
line.separator=

java.vm.specification.vendor=Sun Microsystems Inc.
gnu.classpath.home.url=file:///usr/lib
gnu.gcj.progname=com.install4j.runtime.Launcher
gnu.classpath.version=0.20-pre
java.specification.version=1.4
install4j.jvmDir=/usr/lib/jvm/jre
java.library.path=
gnu.classpath.vm.shortname=libgcj
java.class.version=46.0
java.specification.name=Java(tm) Platform API Specification
os.version=2.6.16.13-4-smp
gnu.classpath.home=/usr
user.home=/home/snjvk
sun.java2d.noddraw=true
file.encoding=UTF-8
os.name=Linux
user.name=snjvk
java.class.path=i4jruntime.jar:user.jar:/usr/share/java/libgcj-java version "1.4
.2".jar
java.io.tmpdir=/tmp
os.arch=i386
java.fullversion=GNU libgcj 4.1.0 (SUSE Linux)
user.language=en
java.specification.vendor=Sun Microsystems Inc.
user.dir=/home/snjvk/Desktop/XSLT/oxygen.sh.17827.dir
java.vm.info=GNU libgcj 4.1.0 (SUSE Linux)
java.version=1.4.2
java.ext.dirs=/usr/share/java/ext
sun.boot.class.path=/usr/share/java/libgcj-4.1.0.jar
java.vm.vendor=Free Software Foundation, Inc.
java.vendor.url=http://gcc.gnu.org/java/
java.vendor=Free Software Foundation, Inc.
file.separator=/
java.vm.version=4.1.0 (SUSE Linux)
http.agent=gnu-classpath/0.20-pre (libgcj/4.1.0 (SUSE Linux))
gnu.gcj.precompiled.db.path=/usr/lib/gcj-4.1.0/classmap.db
gnu.cpu.endian=little
user.region=US
gnu.gcj.runtime.endorsed.dirs=/usr/share/java/gcj-endorsed

Post by **JustinVK** » Mon Jun 12, 2006 8:41 pm

And the actual installation output:

snjvk@linux-u842:~/Desktop/XSLT> sh oxygen.sh
testing JVM in /usr/lib/jvm/jre ...
Starting Installer ...
java.lang.IllegalArgumentException: Couldn't load image: welcome.png
at gnu.java.awt.peer.gtk.GtkImage.<init> (lib-gnu-java-awt-peer-gtk.so.7)
at gnu.java.awt.peer.gtk.GtkToolkit.createImage (lib-gnu-java-awt-peer-gtk.so.7)
at gnu.java.awt.peer.gtk.GtkToolkit.getImage (lib-gnu-java-awt-peer-gtk.so.7)
at javax.swing.ImageIcon.<init> (libgcj.so.7)
at javax.swing.ImageIcon.<init> (libgcj.so.7)
at com.install4j.runtime.installer.frontend.BaseScreen.getBannerIcon (Unknown Source)
at com.install4j.runtime.installer.frontend.BaseScreen.setupComponent (Unknown Source)
at com.install4j.runtime.installer.frontend.BaseScreen.initScreen (Unknown Source)
at com.install4j.runtime.installer.frontend.screens.WelcomeScreen.<init> (Unknown Source)
at com.install4j.runtime.installer.frontend.InstallerWizard.setupScreens (Unknown Source)
at com.install4j.runtime.installer.frontend.InstallerWizard.<init> (Unknown Source)
at com.install4j.runtime.installer.Installer.initWizard (Unknown Source)
at com.install4j.runtime.installer.Installer.access$000 (Unknown Source)
at com.install4j.runtime.installer.Installer$1.run (Unknown Source)
at java.awt.event.InvocationEvent.dispatch (libgcj.so.7)
at java.awt.EventQueue.dispatchEvent (libgcj.so.7)
at java.awt.EventDispatchThread.run (libgcj.so.7)
java.lang.IllegalArgumentException: Couldn't load image: welcome.png
at gnu.java.awt.peer.gtk.GtkImage.<init> (lib-gnu-java-awt-peer-gtk.so.7)
at gnu.java.awt.peer.gtk.GtkToolkit.createImage (lib-gnu-java-awt-peer-gtk.so.7)
at gnu.java.awt.peer.gtk.GtkToolkit.getImage (lib-gnu-java-awt-peer-gtk.so.7)
at javax.swing.ImageIcon.<init> (libgcj.so.7)
at javax.swing.ImageIcon.<init> (libgcj.so.7)
at com.install4j.runtime.installer.frontend.BaseScreen.getBannerIcon (Unknown Source)
at com.install4j.runtime.installer.frontend.BaseScreen.setupComponent (Unknown Source)
at com.install4j.runtime.installer.frontend.BaseScreen.initScreen (Unknown Source)
at com.install4j.runtime.installer.frontend.screens.WelcomeScreen.<init> (Unknown Source)
at com.install4j.runtime.installer.frontend.InstallerWizard.setupScreens (Unknown Source)
at com.install4j.runtime.installer.frontend.InstallerWizard.<init> (Unknown Source)
at com.install4j.runtime.installer.Installer.initWizard (Unknown Source)
at com.install4j.runtime.installer.Installer.access$000 (Unknown Source)
at com.install4j.runtime.installer.Installer$1.run (Unknown Source)
at java.awt.event.InvocationEvent.dispatch (libgcj.so.7)
at java.awt.EventQueue.dispatchEvent (libgcj.so.7)
at java.awt.EventDispatchThread.run (libgcj.so.7)

Post by **george** » Tue Jun 13, 2006 7:44 am

java.vm.name=GNU libgcj

oXygen requires a Java from Sun and you have GNU Java, see on the download page, under requirements:
***
Sun Microsystems Java VM version 1.4.2 or later (available at http://java.sun.com) in case you use the installation kit without Java VM.
***
Eventually you can use the all platforms distribution which is just an archive to install oXygen - but you should make sure you use a Java from Sun when running oXygen after installation.

Best Regards,
George

Post by **pharm** » Tue Oct 31, 2006 8:27 pm

george wrote: Eventually you can use the all platforms distribution which is just an archive to install oXygen - but you should make sure you use a Java from Sun when running oXygen after installation.

Constraining your users to run the Sun JVM is unfortunate. It seems from running oxygen on a non-sun JVM that you're using the sun.security.action.GetPropertyAction class which is failing on other JVMs because that's a class they can't reimplement: it's sun only & completely undocumented.

Sun themselves state that you shouldn't call into the sun.* classes:
http://java.sun.com/products/jdk/faq/fa ... kages.html

What is it that you need that's provided by the sun.* classes?

cheers, Phil

Post by **sorin_ristache** » Wed Nov 01, 2006 1:58 pm

Hello Phil,

pharm wrote:It seems from running oxygen on a non-sun JVM that you're using the sun.security.action.GetPropertyAction class which is failing on other JVMs

I am sorry, your guess is wrong. Only the JVM from Sun Microsystems is supported right now because a JVM from other vendor may not include the standard cryptography provider used by <oXygen/> to verify the license key (for example the GNU libgcj from Free Software Foundation) and first it must be tested extensively before adding it to the list of JVMs officially supported by <oXygen/>. There was a discussion about this recently. As you can read there <oXygen/> may work very well with JVM implementations from other vendors but the eventual incompatibilities will not be solved in further <oXygen/> releases.

Regards,
Sorin

Post by **pharm** » Wed Nov 01, 2006 4:18 pm

sorin wrote:Hello Phil,

pharm wrote:It seems from running oxygen on a non-sun JVM that you're using the sun.security.action.GetPropertyAction class which is failing on other JVMs
I am sorry, your guess is wrong.

I am sorry too, but that's the error from the traceback!
Your code is calling that internal Sun class method. No guesswork involved.

Only the JVM from Sun Microsystems is supported right now because a JVM from other vendor may not include the standard cryptography provider used by <oXygen/> to verify the license key (for example the GNU libgcj from Free Software Foundation) and first it must be tested extensively before adding it to the list of JVMs officially supported by <oXygen/>. There was a discussion about this recently. As you can read there <oXygen/> may work very well with JVM implementations from other vendors but the eventual incompatibilities will not be solved in further <oXygen/> releases.

So you restrict your users to only those platforms on which the Sun JVM has been ported. Pity.

Both the IBM and gcj java implementations provide a JCE implementation: Is it that important to you that Oxygen uses a specific provider implementation?

cheers, Phil

Post by **sorin_ristache** » Wed Nov 01, 2006 5:40 pm

pharm wrote:I am sorry too, but that's the error from the traceback!
Your code is calling that internal Sun class method. No guesswork involved.

<oXygen/> does not call directly a sun.* class. <oXygen/> calls only standard Java classes from java.*, javax.* packages and classes from other packages like com.thaiopensource.*. It is possible that a standard Java class used in <oXygen/> calls the sun.security.* class but I am pretty sure that no <oXygen/> class calls a sun.* class directly. Please post the traceback or a fragment of the traceback to see the sequence of calls to that sun.security.* class.

pharm wrote:Both the IBM and gcj java implementations provide a JCE implementation: Is it that important to you that Oxygen uses a specific provider implementation?

sorin wrote:... and first it must be tested extensively before adding it to the list of JVMs officially supported by <oXygen/>

It is not only the problem of the JCE provider which we know that is missing from the GNU libgcj JVM. As I said before a JVM from other vendor must be first tested extensively and show stable and conformant behavior before we support it officially. For example our experience with the IBM JVM was that it requires and comes with a specific version of the Xerces parser which is older than the Xerces version which comes with <oXygen/> and which is not compatible with <oXygen/>. <oXygen/> includes an improved Xerces parser and the IBM version is not acceptable. Also when we tested <oXygen/> with a Java 1.4.2 virtual machine from IBM the Swing user interface had some serious problems incompatible with a production quality application. <oXygen/> uses only standard Java Swing classes, without calling directly Sun specific implementations, so we expect production quality behavior from the Swing implementation of a JVM before supporting it.

Also there is a major non-functional reason for not endorsing the IBM JVM: there is no public URL for downloading from an IBM website or from other website a J2SE JVM for the Windows platform which is needed for running <oXygen/>. The user is forced to download a quite large development package for Eclipse first and use the IBM JVM included in that package for running <oXygen/>. The IBM policy of forcing Java users to download an IBM development package in order to use their JVM is not acceptable for <oXygen/> users and we do not endorse it.

If <oXygen/> works fine for you with the IBM JVM or with the BEA JVM you are free to use it. The only problem is that if you report a problem that you have in <oXygen/> but is caused by a bug in the JVM implementation or a non conformant JVM implementation we may not fix that problem.

Regards,
Sorin

Post by **pharm** » Wed Nov 01, 2006 7:04 pm

<oXygen/> does not call directly a sun.* class. <oXygen/> calls only standard Java classes from java.*, javax.* packages and classes from other packages like com.thaiopensource.*. It is possible that a standard Java class used in <oXygen/> calls the sun.security.* class but I am pretty sure that no <oXygen/> class calls a sun.* class directly. Please post the traceback or a fragment of the traceback to see the sequence of calls to that sun.security.* class.

Looks like it's inside JideSwingUtilities if I read this correctly:

15:51:10,827 1 ERROR [ main ] ro.sync.ui.application.ApplicationLauncher - java.lang.NoClassDefFoundError: com.jidesoft.swing.JideSwingUtilities
java.lang.NoClassDefFoundError: com.jidesoft.swing.JideSwingUtilities
at java.lang.Class.initializeClass(natClass.cc:701)
at com.jidesoft.plaf.eclipse.EclipseMetalUtils.initComponentDefaults(Unknown Source)
at com.jidesoft.plaf.LookAndFeelFactory.a(Unknown Source)
at com.jidesoft.plaf.LookAndFeelFactory.installJideExtension(Unknown Source)
at ro.sync.ui.application.ApplicationLauncher.B(Unknown Source)
at ro.sync.ui.application.ApplicationLauncher.launch(Unknown Source)
at java.lang.reflect.Method.invoke(natMethod.cc:182)
at ro.sync.exml.Oxygen.main(Unknown Source)
Caused by: java.lang.ClassNotFoundException: sun.security.action.GetPropertyAction not found in ro.sync.util.c

sorin wrote:... and first it must be tested extensively before adding it to the list of JVMs officially supported by <oXygen/>

It is not only the problem of the JCE provider which we know that is missing from the GNU libgcj JVM.

As I've already said, GCJ ships with the JCE. The providers are all defined in the lib/jre/java.security file. It may only be in recent versions perhaps.

As I said before a JVM from other vendor must be first tested extensively and show stable and conformant behavior before we support it officially. For example our experience with the IBM JVM was that it requires and comes with a specific version of the Xerces parser which is older than the Xerces version which comes with <oXygen/> and which is not compatible with <oXygen/>. <oXygen/> includes an improved Xerces parser and the IBM version is not acceptable.

I don't understand why they would conflict: The XML parsers are pluggable if you're using JAXP if I understand things correctly. But I haven't tried, so I'll bow to your experience.

Also when we tested <oXygen/> with a Java 1.4.2 virtual machine from IBM the Swing user interface had some serious problems incompatible with a production quality application. <oXygen/> uses only standard Java Swing classes, without calling directly Sun specific implementations, so we expect production quality behavior from the Swing implementation of a JVM before supporting it.

Also there is a major non-functional reason for not endorsing the IBM JVM: there is no public URL for downloading from an IBM website or from other website a J2SE JVM for the Windows platform which is needed for running <oXygen/>.

I hadn't noticed that: you can only download the JRE if you have an IBM manufactured PC. Very restrictive!

but is caused by a bug in the JVM implementation or a non conformant JVM implementation we may not fix that problem.

This is entirely reasonable of course!

cheers, Phil

Post by **kingargyle** » Thu Nov 02, 2006 4:38 am

IBM JVM, but there are some restrictions in it's use on a Win32 platform:

http://www-128.ibm.com/developerworks/java/jdk/

Also, BEA Jrockit is now a certified platform for Eclipse, so hopefully, future versions of the Eclipse plugin will remain compatible with BEA Jrockit.

Post by **sorin_ristache** » Thu Nov 02, 2006 12:08 pm

pharm wrote:Looks like it's inside JideSwingUtilities if I read this correctly:

15:51:10,827 1 ERROR [ main ] ro.sync.ui.application.ApplicationLauncher - java.lang.NoClassDefFoundError: com.jidesoft.swing.JideSwingUtilities
java.lang.NoClassDefFoundError: com.jidesoft.swing.JideSwingUtilities
at java.lang.Class.initializeClass(natClass.cc:701)
at com.jidesoft.plaf.eclipse.EclipseMetalUtils.initComponentDefaults(Unknown Source)
at com.jidesoft.plaf.LookAndFeelFactory.a(Unknown Source)
at com.jidesoft.plaf.LookAndFeelFactory.installJideExtension(Unknown Source)
at ro.sync.ui.application.ApplicationLauncher.B(Unknown Source)
at ro.sync.ui.application.ApplicationLauncher.launch(Unknown Source)
at java.lang.reflect.Method.invoke(natMethod.cc:182)
at ro.sync.exml.Oxygen.main(Unknown Source)
Caused by: java.lang.ClassNotFoundException: sun.security.action.GetPropertyAction not found in ro.sync.util.c

It is something from the JideSwingUtilities class of the JIDE docking framework library used in <oXygen/>. We will check with the developers of the library. What JVM give that error ? The IBM JVM works OK.

pharm wrote:As I've already said, GCJ ships with the JCE. The providers are all defined in the lib/jre/java.security file. It may only be in recent versions perhaps.

The problem of GNU libgcj is that in the JCE module of that JVM there is no provider for the encryption algorithm used in <oXygen/>. It is a widely used encryption algorithm and all the other JVMs that we tested (from Sun Microsystems and other vendors) provide it. You can check that by running <oXygen/> with other JVMs and registering the <oXygen/> license key in the registration dialog without the error "Invalid key specification: null".

pharm wrote:I don't understand why they would conflict: The XML parsers are pluggable if you're using JAXP if I understand things correctly.

Xerces is used at a lower level than JAXP. Some <oXygen/> features depend on specific behavior of Xerces classes which is different in previous Xerces versions. Also the <oXygen/> version adds improvements not found in the Apache version or the IBM one.

Regards,
Sorin

Post by **pharm** » Thu Nov 02, 2006 12:59 pm

sorin wrote:
pharm wrote:As I've already said, GCJ ships with the JCE. The providers are all defined in the lib/jre/java.security file. It may only be in recent versions perhaps.
The problem of GNU libgcj is that in the JCE module of that JVM there is no provider for the encryption algorithm used in <oXygen/>. It is a widely used encryption algorithm and all the other JVMs that we tested (from Sun Microsystems and other vendors) provide it. You can check that by running <oXygen/> with other JVMs and registering the <oXygen/> license key in the registration dialog without the error "Invalid key specification: null".

Which algorithm? I ask merely for information

-- the gnu classpath people claim full coverage, but that might just be the API, and when you've got pluggable algorithms, implementing the API doesn't necessarily mean anything!

sorin wrote:
pharm wrote:I don't understand why they would conflict: The XML parsers are pluggable if you're using JAXP if I understand things correctly.
Xerces is used at a lower level than JAXP. Some <oXygen/> features depend on specific behavior of Xerces classes which is different in previous Xerces versions. Also the <oXygen/> version adds improvements not found in the Apache version or the IBM one.

I could see that could be problematic, although I don't understand why your own Xerces implementation that you ship as part of Oxygen doesn't take priority over the system one: shouldn't it come first in the classpath? Perhaps that's an IBM JVM bug?

To the previous poster who pointed to the IBM JDK: given that IBM restricts their windows JRE licence to IBM PCs only, I'd check the licencing on that JDK quite carefully: it may well only permit application development, not deployment. On the other hand, you could argue that anyone using Oxygen probably *is* doing application development, so maybe that's OK!

cheers, Phil

Post by **sorin_ristache** » Thu Nov 02, 2006 1:18 pm

pharm wrote:Which algorithm? I ask merely for information -- the gnu classpath people claim full coverage, but that might just be the API, and when you've got pluggable algorithms, implementing the API doesn't necessarily mean anything!

SHA1 with DSA. The JCE providers of GNU libgcj do not provide this algorithm.

pharm wrote:I don't understand why your own Xerces implementation that you ship as part of Oxygen doesn't take priority over the system one: shouldn't it come first in the classpath? Perhaps that's an IBM JVM bug?

The Xerces version included in the IBM JVM is the first in the classpath. I don't know if it is a bug or IBM designed their JVM to be based on their Xerces version.

pharm wrote:it may well only permit application development, not deployment. On the other hand, you could argue that anyone using Oxygen probably *is* doing application development, so maybe that's OK!

If an <oXygen/> user wants to download only the IBM JRE for Windows without the development package for Eclipse on a non IBM PC that is deployment, not development and it is not possible. There are many Windows users with non IBM PC computers so the IBM policy is very restrictive.

Regards,
Sorin

Post by **pharm** » Thu Nov 02, 2006 1:47 pm

sorin wrote: What JVM give that error ? The IBM JVM works OK.

Sorry, missed that question: it was GCJ 4.1

Could be a GCJ bug I suppose, but I can't see why their java api would mention the sun.security.* classes! There's something about it on the gnu pages I found with a quick google here:
http://developer.classpath.org/mediatio ... 0af1986e6a

Does that seem relevant?

cheers, Phil

Post by **sorin_ristache** » Thu Nov 02, 2006 2:06 pm

It is not a GCJ bug. The sun.security.* reference is in the JIDE library but other JVMs implement all the sun.security.action.* classes (for example the IMB JVM). There is a Sun recommendation to avoid calling sun.* classes directly but it seems the sun.security.action.* classes are generally implemented by JVMs and the JIDE library calls such a class. We wait for a reply from the JIDE developers about it.

Regards,
Sorin

Post by **pharm** » Thu Nov 02, 2006 2:09 pm

sorin wrote:
pharm wrote:Which algorithm? I ask merely for information -- the gnu classpath people claim full coverage, but that might just be the API, and when you've got pluggable algorithms, implementing the API doesn't necessarily mean anything!
SHA1 with DSA. The JCE providers of GNU libgcj do not provide this algorithm.

The docs claim they do:
http://developer.classpath.org/doc/java ... ature.html

Rootling through the CVS, it looks like those classes were only checked into the mainstream gnu classpath release at the beginning of 2006 though, so they're probably only in recent gcj releases (4.1+ at a guess).

sorin wrote:
pharm wrote:I don't understand why your own Xerces implementation that you ship as part of Oxygen doesn't take priority over the system one: shouldn't it come first in the classpath? Perhaps that's an IBM JVM bug?
The Xerces version included in the IBM JVM is the first in the classpath. I don't know if it is a bug or IBM designed their JVM to be based on their Xerces version.

I suppose if it really mattered you could rename your xerces package to something else. But given the restrictions mentioned below I can see why you don't really see the point!

sorin wrote: If an <oXygen/> user wants to download only the IBM JRE for Windows without the development package for Eclipse on a non IBM PC that is deployment, not development and it is not possible. There are many Windows users with non IBM PC computers so the IBM policy is very restrictive.

Yup! I hadn't noticed it was so restrictive (those terms don't seem to apply to the IBM linux JVM for some reason). It's even more weird now that IBM has sold their entire PC business to Lenovo!

I can quite understand not being keen on the IBM jvm for that reason alone...

cheers, Phil

Post by **sorin_ristache** » Thu Nov 02, 2006 3:18 pm

pharm wrote:Rootling through the CVS, it looks like those classes were only checked into the mainstream gnu classpath release at the beginning of 2006 though, so they're probably only in recent gcj releases (4.1+ at a guess).

We received many complaints recently about the license registration problem with the GNU JVM which is installed by default by the Ubuntu distribution. Maybe Ubuntu is bundled with an older version of the GNU JVM. Also we need to test more extensively the recent release that provides the SHA1 with DSA algorithm so in the short term <oXygen/> will not support this JVM.

Regards,
Sorin

Post by **pharm** » Thu Nov 02, 2006 4:00 pm

sorin wrote: We received many complaints recently about the license registration problem with the GNU JVM which is installed by default by the Ubuntu distribution. Maybe Ubuntu is bundled with an older version of the GNU JVM. Also we need to test more extensively the recent release that provides the SHA1 with DSA algorithm so in the short term <oXygen/> will not support this JVM.

It's moot anyway right now: using gcj to run oxygen doesn't seem to work anyway due to the aforementioned sun.security. method call, at least on the machine in front of me...

If you get a patch from jidesoft let me know if you want me to give it a try.

cheers, Phil