-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 8 Jul 2001, Frank Meurer wrote:
[installing Java library .jar files]
>>Sun sometimes recommend that you install new .jar files in
>>/usr/java/jre/lib/ or /usr/java/jre/lib/ext/. Then they get picked up
>>automatically without needing to be in the CLASSPATH. But I think this
>>is not really appropriate for stuff that doesn't come from Sun, and I'm
>>not sure that /usr/java/ is a good place for anything, although Sun seem
>>to have claimed it.
>
>Why not?
Well, it's an okay place for the official Sun JDK. Sun distribute an
RPM for Linux that installs in /usr/java/, with an elaborate directory
structure underneath for binaries, .jar files and so on.
What Sun do, IIRC, is to have /usr/java/jdk-1.3.1/ and under there a
jre/lib/ directory for libraries. We can't make other packages
dependent on the '1.3.1' bit, and we can't really make them depend on
knowledge of Sun's odd directory structure, which might change in the
future.
So some other place is needed. You could make another directory under
/usr/java/, such as /usr/java/lib/, but I think it might be more
FHS-compliant to have something under /usr/share/.
>Which JDKs and JRE do actually behave like you described???
I don't know; what I do know is that with Sun's JDK you can dump
packages into /usr/java/jdk-1.3.1/jre/lib/ext/ and they'll magically
start working. But this is not very deep magic, it could easily be
reproduced for a different directory with a simple shell script or
wrapper for 'java'.
>>I propose that Java libraries be installed under
>>/usr/share/java/,
>Agreement but what says the Linux Standard Base?
Nothing specific in there about Java. Do you mean the FHS? There's
noting about Java in there either, but it does say:
>18. Miscellaneous architecture-independent application-specific
>static files and subdirectories must be placed in /usr/share.
That sounds like Java libraries... OTOH, they are libraries, despite
being architecture-independent, so maybe /usr/lib/ is better. After
all, Perl libraries go in /usr/lib/perl5/ not under /usr/share/. (Goes
and checks the FHS) Oh no, the FHS specificially covers this:
>19. For example, the perl5 subdirectory for Perl 5 modules and
>libraries.
Right. So even though something may be a 'library' in some sense, if
it's architecture-independent it should go in share/ not lib/.
>I would prefer this directory /usr/share/java/ and a symlink to it from
>/usr/java.
I am a bit annoyed that Sun unilaterally decided to grab the directory
/usr/java/ and install random stuff under it in a not very sensible
directory layout. They can do that on Solaris if they want, but
preferably not Linux. I don't think we should encourage them by putting
anything more in there :-)
Since /usr/java/ contains binaries, documentation and all sorts of
stuff, I don't think it's appropriate for /usr/share/, which I think is
for architecture-independent files (like Java libraries!).
>>for i in /usr/share/java/*; do
>> export CLASSPATH=$CLASSPATH:$i
>>done
>But... maybe there will be (with a /huge/ growing number of jars etc.)
>some broken dependencies or conflicts due to the wrong sequence of jars in
>CLASSPATH.
Mostly this will not happen due to Java's package rules. A library from
one vendor will have classes called
com.snakeoil.palisade.Whatever
and another vendor will use
com.gerbil-gratings.simphoni.Whatever
so they can't clash. This even happens for different libraries
implementing the same spec, such as XML DOM. You set a string in your
source code to decide whose implementation to use.
>E.g.: You install a package which needs i.e. the new JMF 2.1.1 and
>comes with it. For /this/ software the new jmf jar must be prepended to
>the old classpath. If the installer and/or /etc/profile does it right then
>the new software will run, but /old/ software which needs the old JMF 1.x
>won't run anymore.
Ah, but that is the same problem you have with RPM packages anyway. The
way people often get around this is to make the new, incompatible
version install with a different name, eg 'bash2'. (Or maybe rename the
old version, as in 'bash1'.) I expect that this also happens when Java
libraries get incompatible new versions, eg:
com.snakeoil.palisade4_2_1.Whatever
com.snakeoil.palisade5_3_0.Whatever
Really you have to say that it's up to the library author. However if
users do want finer control over what .jar files get searched first they
can always edit their CLASSPATH themselves. I think that most likely
they would just add the necessary .jar files to the front.
>And what about a *big* CLASSPATH if you have installed dozens of java
>packages?
Not a problem - if you've installed dozens you presumably want to use
them all. Considering the general speed of Java, I don't think the
small extra startup time would be significant :-)
Again, if you do want fine control over this, you could set CLASSPATH by
hand. But the default setup should be that you can install some
libraries and have them Just Work.
- --
Ed Avis <[EMAIL PROTECTED]>
Finger for PGP key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7SHXLIMp73jhGogoRAm8aAJ91cy0459HBWWRFPscja77NN4XqswCfUx49
u/ndXFP+8bEkiWcWNcYUQXw=
=EWku
-----END PGP SIGNATURE-----
