Apache OpenOffice (AOO) Bugzilla – Issue 43103
javaldx very slow and yields no answer
Last modified: 2005-02-28 16:28:25 UTC
$ env LD_LIBRARY_PATH=/opt/openoffice.org1.9.79/program time /opt/openoffice.org1.9.79/program/javaldx javaldx: Could not find a Java Runtime Environment! 23.88user 2.68system 0:37.14elapsed 71%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (56major+345144minor)pagefaults 0swaps My complaint is not with the inability to find a JRE (as that's been covered in several other issues here) but rather with it taking 25 seconds and 70% of the CPU to reach this conclusion. If I replace $OO_HOME/program/javaldx with a shell script my OpenOffice load times are just stunning. It behaved the same way in all the 680 builds I have tried.
Hi mdaniel, thanks for using and supporting OpenOffice.org... AFAIK Office try to find java in all usual places and starts each found java to make sure it works correctly and can be used in the Office reassigned to jl mci -> jl: Hi jl, do you see a way to decrease the time which is needed? It works but it's slow... :(
Javaldx is nessecary for Java to work. This however is a workaround for a Java bug. Because the JRE is not properly linked and needs to rely on the LD_LIBRARY_PATH to find its libraries, which happen to reside in the same installation. Many other vendors copied this bug and hence also depend on javaldx. Because it is not specified how a JRE is to be located, we need to search several locations in the filesystem. Also if a JRE was found it needs to be started to find out such things as vendor name, version, accessibility support. Typically only at the first startup javaldx takes such a long time. If if finds a proper JRE then the next time the office starts up it uses the recently found JRE and does not search for others. I suppose that a JRE was found but it was rejected because it did not meet the version requirement of 1.4.1 (this requirement will be lowered to 1.3.1 soon). Could you confirm this? What JREs are on your system (location, version, vendor)? Are they all located on a local volume?
I forgot to mention that my environment contains JAVA_HOME and is set to the proper value. I use update-alternates to create symlinks in /usr/bin that always point to the proper java binary, too. > What JREs are on your system (location, version, vendor)? Are they all located > on a local volume? $ /usr/java/jdk1.5.0_01/bin/java -version java version "1.5.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_01-b08, mixed mode) > Typically only at the first startup javaldx takes such a long time. If if > finds a proper JRE then the next time the office starts up it uses the > recently found JRE and does not search for others. So can I manually insert my JVM into its cache file to keep it from searching? If that is what Tools,Options,Java is supposed to do, when I click Add, select "/usr/java/jdk1.5.0_01" I get the message "The folder you selected does not contain a Java runtime environment". It does that for $JAVA_HOME/bin and $JAVA_HOME/jre (and /bin), also. > I suppose that a JRE was found but it was rejected because it did not meet > the version requirement of 1.4.1 (this requirement will be lowered to > 1.3.1 soon). So when you say lowered, that to me means the "cost of entry" is 1.3.1, not "the only supported version" is 1.3.1. I will go try and find 1.4.1 for amd64 and see if that works, but I don't understand why a 1.5 JVM isn't compatible with 1.4.1. It certainly is from a Java stance. Thanks for your help with this.
The JRE should be found, either because you set JAVA_HOME or because of the location. >So can I manually insert my JVM into its cache file to keep it from searching? Yes >If that is what Tools,Options,Java is supposed to do, when I click Add, select >"/usr/java/jdk1.5.0_01" I get the message "The folder you selected does not >contain a Java runtime environment". It does that for $JAVA_HOME/bin and >$JAVA_HOME/jre (and /bin), also. That's exactly the way to do it if the no JRE was automatically found. >So when you say lowered, that to me means the "cost of entry" is 1.3.1, not "the >only supported version" is 1.3.1. I will go try and find 1.4.1 for amd64 and see >if that works, but I don't understand why a 1.5 JVM isn't compatible with 1.4.1. >It certainly is from a Java stance. 1.3.1 will be the minimum version for many OO platforms. This is because there is some requirement that a 1.3.1 must be usable to build the Java projects. Anyway in your case it doesn't matter. To find out what goes wrong we have to find out if the JRE can be successfully run from javaldx and what the Java System properties are. Let's start with the properties. I will attach a small Java program which prints out all System properties. Could you run it and paste the output here? To run it go into the directory where you put the program and call /usr/java/jdk1.5.0_01/jre/bin/java Props
Created attachment 23023 [details] Prints out System properties
Another questions, the output of java -version indicates that you're running a 64 bit version of the JRE. Do you also have a 64 bit Linux installed?
$ java Props java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition sun.boot.library.path=/usr/java/jdk1.5.0_01/jre/lib/amd64 java.vm.version=1.5.0_01-b08 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) 64-Bit Server VM file.encoding.pkg=sun.io user.country=US sun.os.patch.level=unknown java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/mdaniel java.runtime.version=1.5.0_01-b08 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment java.endorsed.dirs=/usr/java/jdk1.5.0_01/jre/lib/endorsed os.arch=amd64 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. os.name=Linux sun.jnu.encoding=UTF-8 java.library.path=/usr/java/jdk1.5.0_01/jre/lib/amd64/server:/usr/java/jdk1.5.0_01/jre/lib/amd64:/usr/java/jdk1.5.0_01/jre/../lib/amd64 java.specification.name=Java Platform API Specification java.class.version=49.0 sun.management.compiler=HotSpot 64-Bit Server Compiler os.version=2.6.10-mh1 user.home=/home/mdaniel user.timezone= java.awt.printerjob=sun.print.PSPrinterJob file.encoding=UTF-8 java.specification.version=1.5 user.name=mdaniel java.class.path=. java.vm.specification.version=1.0 sun.arch.data.model=64 java.home=/usr/java/jdk1.5.0_01/jre java.specification.vendor=Sun Microsystems Inc. user.language=en java.vm.info=mixed mode java.version=1.5.0_01 java.ext.dirs=/usr/java/jdk1.5.0_01/jre/lib/ext sun.boot.class.path=/usr/java/jdk1.5.0_01/jre/lib/rt.jar:/usr/java/jdk1.5.0_01/jre/lib/i18n.jar:/usr/java/jdk1.5.0_01/jre/lib/sunrsasign.jar:/usr/java/jdk1.5.0_01/jre/lib/jsse.jar:/usr/java/jdk1.5.0_01/jre/lib/jce.jar:/usr/java/jdk1.5.0_01/jre/lib/charsets.jar:/usr/java/jdk1.5.0_01/jre/classes java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle sun.desktop=gnome sun.cpu.isalist= ##### In answer to your other question, I am running Fedora Core 3 (x86_64) on an Averatec 6235-EE1 with 2G of RAM. I have a custom 2.6.10 kernel, if that matters. ##### To follow up on what I said yesterday, I downloaded J2SE 1.4.2_07 (but only i386, they don't have an amd64 version of 1.4) and installed it. Now javaldx outputs the expected LD path and did cache it so subsequent runs only take 0.014 seconds. $ /opt/openoffice.org1.9.79/program/javaldx /usr/java/j2sdk1.4.2_07/jre/lib/i386/client:/usr/java/j2sdk1.4.2_07/jre/lib/i386/native_threads:/usr/java/j2sdk1.4.2_07/jre/lib/i386 $ /usr/java/j2sdk1.4.2_07/jre/bin/java -version java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)
It seems that cause for this issue is founded in a different directory structure. I assume that the libraries are contained in ../jre/lib/amd64/ This is fixed in cws ooo64bit02 which is scheduled for integration at 2005-03-15. (/cvs/udk/jvmfwk/plugins/sunmajor/pluginlib/vendorbase.hxx, 1.2.18.3) Thanks for your help. *** This issue has been marked as a duplicate of 8584 ***
I just noted that ooo64bit02 is targeted for OOo2.0.1. Since this issue is not really a 64bit issues we should fix it for OOo2.0.
.
Thinking about it, i came to the conclusion that we must not mix a 32 bit build with a 64 bit Java. The reason is that we use JNI which uses the native pointers. Therefor we needed a true 64 bit OOo which also uses the jni.h from 64 bit Java. Otherwise, we may cause crashes which are really hard to reproduce. JL->mdaniel: I recommend to use a 32 bit Java along with a 32 bit OOo. But I can't say for sure if this works reliably on a 64 bit platform, since this is not officially supported yet. However, there is a 64 bit port underway as I indicated recently. Thanks anyway for supporting us.
I'm not going to reopen this, I'll leave that decision to you, but ... Don't forget that my original issue wasn't with its inability to find a JRE (32 bit or 64 bit or 128 bit), it was that it took 37.14 seconds to decide it didn't want to work. My point is that either it should find one and use it or get out of the way; don't cause my OOo startup to be delayed just because of its indecision. Now, if the "solution" is for the user to rename javaldx if s/he doesn't want (or can't support) a JRE with OOo, that's okay, too, I just want to know if I should plan for that during my upgrades.
>I'm not going to reopen this, I'll leave that decision to you, but ... >Don't forget that my original issue wasn't with its inability to find a JRE (32 >bit or 64 bit or 128 bit), it was that it took 37.14 seconds to decide it didn't >want to work. An official 64 bit build of OO should be able to use your JRE. Your current configuration (32bitOOo, 64bitJRE) is unsupported. For OOo you need to install the 32 bit JRE. >My point is that either it should find one and use it or get out of the way; >don't cause my OOo startup to be delayed just because of its indecision. Java is needed for UNO components which is the foundation of OOo. That is, a fully functional OOo needs a JRE. Currenty there is still the possibility to disable Java in the options dialog. But there are also OOo build (Debian distribution) which build OOo in a way that Java is not needed (and hence Java - Uno components do not work) >Now, if the "solution" is for the user to rename javaldx if s/he doesn't want >(or can't support) a JRE with OOo, that's okay, too, I just want to know if I >should plan for that during my upgrades. The solution is to install OOo and a proper JRE as a "bundle", disable the JRE in the options dialog, or use a "Java-disabled" OOo. However, switching of Java in the options dialog, may cause a lot of message boxes if Java functionality is used. This can be the case if you load a document with embedded java macros. Removing javaldx from the script is a bad idea, because some other code searches for a JRE as well. And if it finds a usable JRE and starts it then the Java VM will crash the office.