> From: "Haricharan Ramachandra" <[EMAIL PROTECTED]> > I checked the Java version and it is Jdk1.4.2 on my machine, i got to know > from Herve that it might be due to the Linux 32/64bit version problem. but > on the download website there is no mantion of 32/64 bit version for the > Linux JXplorer.
You may have a 1.4.2 VM installed (which one? java.sun.com? Blackdown? IBM?) but the stack trace clearly indicates that you weren't using that one but a GNU gcj based version (which is probably Java 1.1, too old for JXplorer). That means the ZeroG script is picking the wrong VM. Try setting the JAVA_HOME environment variable to the base directory of the Java installation you wish to use before running the installer. About 32 vs. 64 bits: indeed JXplorer shouldn't care whether the Java VM is a native amd64 executable or an i386 one. But there *are* amd64 JVMs out there. From java.sun.com you can get a 64-bit Java 5.0 VM, which should work with JXplorer 3.2 beta but maybe not so well with 3.1. >From blackdown.org, on the other hand, you can get a 64-bit 1.4.2 VM, complete with Mozilla browser plug-in. (You don't need that plug-in to run JXplorer, and Red Hat 9 probably shipped with a 32-bit mozilla anyway, but some other readers might care.) One potential problem with 64-bit JVMs and the ZeroG installer: at least some versions of that installer try to check for JVMs with known security holes, and do this by setting the LD_ASSUME_KERNEL environment variable internally. This can cause an amd64 installation to fail for no good reason. I haven't checked whether the JXplorer installer is affected by this (I installed it using the deploy tarball instead); it might be. > > Stack Trace: > > java.lang.NoClassDefFoundError: while resolving class: ZeroGe > > at java.lang.VMClassLoader.resolveClass(java.lang.Class) > > (/usr/lib64/libgcj.so.5.0.0) > From: Hervé BOUTEMY <[EMAIL PROTECTED]> > The 32/64bit version question does not affect JXplorer itself, but Linux and > JVM : programs written in Java (like JXplorer) are not dependant on such > questions, they are dependant on a JVM and its version. > Since you've got a 1.4.2 JVM, the problem is not on the version of the JVM > that JXplorer needs. I agree so far. > Now we can conclude that the bug lies in the JVM : JXplorer can't do anything > about it. That doesn't follow. If there is a bug here (as opposed to mere "user error"), it's in the ZeroG installer. > The only hope is that the JVM bug is triggered by the graphical installer > (ZeroG) : if you download .tar.gz version of JXplorer, this installer isn't > there. Perhaps JXplorer itself will work on the buggy JVM... The JVM is probably working as it's supposed to. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jxplorer-users mailing list Jxplorer-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jxplorer-users
