Issue 64357 - javaldx search too promiscuously
Summary: javaldx search too promiscuously
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: All Unix, all
: P2 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: Olaf Felka
QA Contact: issues@framework
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2006-04-13 00:59 UTC by quenelle
Modified: 2009-08-20 13:23 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description quenelle 2006-04-13 00:59:52 UTC
My machine has an auto-mounted directory called /java which links to many
many NFS filesystems inside on many different hosts.  When I try to run a program called "javaldx" searches in many places on my system
for a JDK.

1971:   access("/j2re", F_OK)                           Err#2 ENOENT
1971:   access("/j2se", F_OK)                           Err#2 ENOENT
1971:   access("/j2sdk", F_OK)                          Err#2 ENOENT
1971:   access("/jdk", F_OK)                            Err#2 ENOENT
1971:   access("/jre", F_OK)                            Err#2 ENOENT
1971:   access("/java", F_OK)                           = 0
1971:   access("/java", F_OK)                           = 0
1971:   lstat("/java", 0xFFBFE04C)                      = 0

Now the /java directory will not have anything helpful, but javaldx searches
a whole bunch of subdirectories anyway.

For EACH and EVERY subdirectory inside /java the program searches for
the following inner subdirectories:

1971:   getdents64(4, 0xFF3A4000, 8192)                 = 2136
1971:   access("/java/jle_build", F_OK)                 = 0
1971:   lstat("/java/jle_build", 0xFFBFE04C)            = 0
1971:   access("/java/jle_build/java", F_OK)            Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/gij", F_OK)             Err#2 ENOENT
1971:   access("/java/jle_build/bin/gij", F_OK)         Err#2 ENOENT

Sooner or later, it comes to a filesystem that won't respond over NFS and
the whole process hangs, which hangs

I see multiple possible solutions to this:

1. don't search in ALL subdirectories of /java, just the directory names
that look like they might have a JRE inside.

2. search in a different and more intelligent order, so that my
Solaris 10 system results in a match before the search process
gets to /java. (And stop when you get a good match)

3. Set a timeout on the thread which is doing this probe so that a hang
doesn't hang forever (or shorten the time out if there is already one).
Don't rely on the OS'es NFS timeout to be the only limit.
Comment 1 Olaf Felka 2006-04-13 09:25:12 UTC
I don't see this as a defect because it 'works as designed'. Maybe a redesign
will be helpfull. @ jl: Please have a look.
Comment 2 joachim.lingner 2006-04-13 14:59:34 UTC
Unfortunately it is not defined where the Java installation has to be. Different
vendors install it in different places. Also the internal structure of the
installation is not specified and the structure may differ in different versions
from one vendor. Thats why there are so many combinations of paths which are

Stopping the search after one Java has been found is no option, because the user
could then not select between several Javas in the options dialog.

Using a timeout seems the best solution.

Comment 3 joachim.lingner 2006-04-13 17:03:40 UTC
After further consideration, I think we should not reinvent the wheel here and
require that the system handles mounted volumes properly. If they are mounted
hard, then this was done intentionally and all application will block which try
to access them. Therefore the volumes should be mounted "soft" with a timeout
that satisfies all applications.

If we assume that many users just does not know how volumes are mounted and are
not capable of setting up the system properly, then it may be a good idea if
javaldx gives a notice to the user that a path is unreachable. However, a
typical home computer does not have mounted other volumes. This probably happens
more often in companies. There, they should have IT people which can set up the
system properly. 

Therefore I  do not see the need for coding an additional timeout in OOo.
However a notice would be nice saying something like "Access to path to /xyz
seems to be blocking. Please check that the volume is mounted soft and with a
proper timeout. "
But I am not sure if its worth to use a messagebox here. This would either
involve using vcl in javaldx or using platform dependent code. Because more
often then not OOo is started by clicking some  Icon in the GUI, we would have
only half a solution (we could still write something into the console).

For these reasions I think OOo is not the right place to fix it. The only option
may be to add some advise to the readme.
Comment 4 quenelle 2006-04-13 20:53:04 UTC
Could you summarize the different directories that are searched for a JRE?
Is this list of directories different for different platforms?
There is no reason to search in /java if you are on Solaris.

Even across ALL platforms:
If you are searching for directories like:

then there is no need to search:

If you summarize the known list of pathnames where java
is sometimes found maybe I can suggest some changes to
limit this scope.

On windows, can't you use the registry to find the places where
java is installed on the system?  That would avoid searching 
a whole bunch of directories.
Comment 5 joachim.lingner 2006-04-18 13:00:57 UTC
We do not search for particular directory names, such as JDK1.5.1 etc. At least
not for SUN JREs. The reason is that it is not specified how the installation
directories are named and the naming pattern changes every now and then (which
may also be different with different vendors). Also users may rename their
Therefore all subdirectories are examined if they represent a JRE installation.
The path to these subdirectory is dynamically created.
Best thing is to have a look at jvmfwk/plugins/sunmajor/pluginlib/util.cxx,
function createJavaInfoDirScan.

On windows the registry is used, among other things (PATH and JAVA_HOME).
Comment 6 quenelle 2006-04-20 20:55:26 UTC
Is there a command line option to open office that specifies the full pathname
to the JRE that it should use?  Or some way to tell it not to look for a JVM?
Comment 7 joachim.lingner 2006-04-21 16:58:30 UTC
>Is there a command line option to open office that specifies the full pathname
to the JRE that it should use?


> Or some way to tell it not to look for a JVM?
Only in the options dialog. There you can switch off using a JRE. But when
starting the office for the first time it will still search for JREs.
Comment 8 quenelle 2006-04-21 17:16:51 UTC
Solaris has a very well-defined set of places that Java JREs can be
stored.  It would be helpful to have javaldx look at which style of UNIX
you are running on, and search directories based on that.

On Solaris, all the installed versions of Java should be under /usr/jdk
(with multiple JRE versioned directories inside there)

The tool eventually comes up if I let it sit long enough, so I can do that,
then disable java in the properties.  I'll try that and see if it's better.
Comment 9 joachim.lingner 2006-04-25 16:46:03 UTC
Te be fully functional OOo must find a JRE. Problem with that is, that we still
support JREs back to 1.3.1 and JREs from vendors other then SUN. And I doubt
that JREs were always installed in the same place. As I indicated there is no
specified way of finding the Java runtime (thats is the runtime dll), nor is
there a generic way to obtain the Java Virtual Machine. Therefore this excessive
search is done. 
I do not think it is a good idea to limit the set of  paths which are used for
searching. But I also admit that this may lead to problems as in your case.
Currently there is no satifying solution.

Comment 10 quenelle 2006-04-26 23:17:34 UTC
Is it possible to search in different directories depending on 
which version of UNIX you are running on?  The rules for Solaris
can be different than the rules for Linux.  Solaris is much
better controlled and standardized.
Comment 11 joachim.lingner 2006-04-27 09:33:16 UTC
We do not distinguish Solaris and Linux when searching the file system. But you
have to bear in mind that a "standard" location and name of the installation
directory may only be available if the JRE was preinstalled or by the package
mamager. Still there are JREs as .bin or .sh files which can be installed
anywhere,  names can changed and links removed.

What you have probably in mind is to restrict the search to just a couple of
standard paths. However, as I indicated earlier, OOo depends on finding a JRE to
be fully functional. The objective is that a user installs the office and can
use it right away. Many "common" people do not know what Java is for and do not
care. And having them select a JRE manually from the options dialog may be big
hurdle. From my point of view we have only these possibilities.

1. A JRE is ALWAYS installed with OOo at a defined location.
2. Do a comprehensive search in order to find the best JRE possible.
3. Have a platform and vendor independent way of obtaining a Java Virtual
Machine at runtime.

1 is not possible because some guidelines prevent this (SOLARIS), and is
politically not feasible.
2 works reasonably but has its drawbacks
3. Different Java vendors have not realized how difficult it is for applications
to use a java runtime in process. Ideally a application would simply link
against a library and obtain a virtual machine by simply calling a function. But
this is not possible right now.

So we stick with 2 for the time being.

Comment 12 quenelle 2006-04-28 00:31:08 UTC
Here is what I would recommend:

1. learn to identify which platform you are on:

2. Search first in "standard" locations for the current OS.
   Collect possible JRE's from these places.
   If you find at least 1 JRE, then you are done.

3. If you haven't found any JRE's yet, then look in all
   possible places that might have a JRE (using all the paths you do now).

If OOo picks the 'wrong' JRE and the user wants a different one, they can
always pull up the properties window and add specific paths to JRE's.
Comment 13 joachim.lingner 2006-05-19 08:57:25 UTC
Comment 14 radbobd 2009-05-11 23:12:49 UTC
This is a potentially huge issue on multi-user Unix machines. In our Enterprise
we have a great many mountpoints under /java since it is an automount map which
has existed for many years and like many such enterprise databases is not
particularly well maintained as admins come and go. Consequently it can take up
to *30 minutes* on first startup for OpenOffice due to searching that point and
encountering stale/obsolete references.

For a given server with many users, the "right" JRE is in the same place for
everyone. So an admin ought to be able to configure a path, thus averting the
need for users to do so.

Since this is a chooser anyway, why not first prompt the user/admin and allow
them optionally to specify a path to the desired JRE, or allow a "browse fs"
selection? The current "search everywhere to provide a set of selectable
alternatives" algorithm should be another option, rather than the only one.

I'm not sure how to change the priority of an Issue but it seems to me it should
be at least a P2 given the potential severity of impact on many sites.

Please consider addressing this issue at the earliest opportunity. It could be
as simple as a command line an admin could use to specify a path which obviates
the need for users to run the "search everywhere" algorithm, if we don't have
time for something fancier.

Thanks for your consideration.
Comment 15 mdxonefour 2009-05-12 07:21:56 UTC
MD->JL: As discussed please fix this for 3.1.1 release.
Comment 16 joachim.lingner 2009-05-13 12:10:14 UTC
Fixed for Solaris. See follow-up issue 101875.
Comment 17 joachim.lingner 2009-05-13 12:14:29 UTC
@OF: Please verify.
Comment 18 Olaf Felka 2009-06-08 14:32:26 UTC
of: verified in cws ooo31osol.
Comment 19 thorsten.ziehm 2009-07-20 14:54:41 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>
Comment 20 thorsten.ziehm 2009-07-20 15:36:24 UTC
Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.
Comment 21 thorsten.ziehm 2009-07-20 15:40:43 UTC
Set to state 'fixed'.
Comment 22 thorsten.ziehm 2009-07-20 15:44:42 UTC
Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.
Comment 23 Olaf Felka 2009-08-20 13:23:24 UTC
Issue fix has been confirmed by 'OOo on OSOL' users. Thanks for helping.