[lsb-discuss] LSB conf call notes for 2008-06-04

[Joseph Kowalski]

Wichmann, Mats D wrote:
>>>>> Darren: distros do need to ship multiple JVMs.
>>>>>           
>>>> Statement or question?
>>>>         
>>> Statement.
>>>       
>> Hummm,... I'm lost.  Perhaps "distros need to be able to ..."?
>>     
>
> I think more that anything that supposes specific paths when
> there may need to be more than one is a concern. For example, 
> saying "it" must be in /usr/lib/java might not be adequate if
> a distro feels they need to supply, concurrently, a 32-bit
> jvm in /usr/lib/java and a 64-bit java in /usr/lib64/java,
> with the different paths being to insure no clash. That's
> an example, I'm not saying specifically those paths.
>   

But, as far as the LSB is concerned, there is just one, right?
/usr/bin/java is the LSB interface, and that's the end of the story.

That said, I understand your concern, but it is far from clear what the
right thing is to do.  Currently, there isn't a good story for
co-resident 64-bit/32-bit Java on Linux (from anybody, including Sun).

OK, so we could invent one....

Your example seems to be down the right path....

    /usr/lib/java/jre1.6.0
    /usr/lib/java/jre1.6.0_06 -> /opt/sun/java/jre1.6.0_06

    /usr/lib64/java/jre1.6.0
    /usr/lib64/java/jre1.6.0_06 -> /opt/sun/java/jre1.6.0_06

This would be an example where the distro provided 1.6.0 (both flavors)
and later (newer) versions were added from java.sun.com.

There is some precedent for this.  On Solaris, both versions (64/32) appear
under the same "root"....

    $JAVAHOME/jre/lib
    $JAVAHOME/jre/lib/amd64

These directories (mostly) just contain the native code (*.so).  The Java
parts don't care how about how many bits.

The launcher (java) can take options (-d32/-64) to select which one (see
man page excerpt below).  (Of course, if a 32-bit processor is sitting
below all of this, it doesn't work too well.)

Consider the above example and the following command line on a 64-bit
distro...

    java -d32 -version:"1.6.0_02+" foo.class

The link /usr/bin/java -> /usr/lib64/java/jre1.6.0/bin/java starts the 
"default" launcher.
It interprets the options and re-execs itself into 
/usr/lib/java/jre1.6.0_06/bin/java.

(The version specification is defined by JSR056 and in this case 
specifies to use an
available version greater than 1.6.0_02, so it uses 1.6.0_06.)

Please feel free to comment on this "invention".  Getting consensus on 
things
like this on linux, is one of the things I want to accomplish.  As I 
said, I'm
frustrated about all the "bug reports" about things like this on linux - 
too many
divergent views about how things should work... one man's bug is another 
man's
feature.

- jek3






        -d32

        -d64
           Request that the program to be  run  in  a  32-bit  or
           64-bit  environment,  respectively.  If  the requested
           environment is not installed or is not  supported,  an
           error is reported.

        Currently only the Java HotSpot Server VM supports 64-bit
        operation,  and the "-server" option is implicit with the
        use of -d64. And the "-client" option is ignored with the
        use  of  -d64.  This  is  subject  to  change in a future
        release.

        If neither -d32 nor -d64 is specified, the default is  to
        run  in a 32-bit environment, except for 64-bit only sys-
        tems. This is subject to change in a future release.