[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages that require Java 2 ?



Hi!

Thanks for the information Ben. I didn't realise the water could get so cloudy
so quickly! :-)

Stephen Zander just wrote in that i386 j2dk packages will be in incoming by the
of the week which will help (BTW - what are the package names going to be
Stephen j2sdk/j2dk/jdk1.3/... ?).

Seeing we cannot easily check for a java2 environment using -version, how can
we ensure the user has a java2 environment ? especially for people who choose
to use IBM or Sun's JDK, and for people who may have both a java1 and java2
environment available ?

java2-virtual-machine/dummy packages would help settle dependancies for non
Debian packaged JDK's, java2 compliant Debian packages could 'provide' this.
We could then 'depend' on it.

The next question is finding the right java binary to run. I'm not so sure
about how to do this best ?

The java2-virtual-machine-dummy package could handle the issue for non Debian
packaged JDK's (via an /etc config file), but how do we manage it for Debian
packaged JDK's - perhaps we should introduce java2 in /etc/alternatives ?

Just thoughts so far.... Any other ideas ?

Cheers,

Marcus


On Tue, 4 Sep 2001, Ben Burton wrote:

> 
> Okay, not to throw a proverbial spanner in, but:
> 
> One point to note is that j2sdk1.3 and j2re1.3 are not yet in debian at all.  
> I believe (correct me if I'm wrong) that a package in debian can't depend on 
> a package outside of debian.
> 
> > This way, a user can install Sun's or IBM's JDK to /usr/local and install
> > your package without breaking its dependencies. You could test if the
> > JVM is Java 2 (either "java -version" or looking for
> > $JAVA_HOME/jre/lib/rt.jar) and print an error message if it's just JDK1.1.
> 
> If you're using /usr/bin/java you need to be careful since it may point to 
> some other JVM and the "java -version" outputs are not at all consistent and 
> sometimes don't even reflect the JDK version.  See below for sample output 
> from different JVMs.
> 
> As for $JAVA_HOME, one must remember that policy (10.9) dictates that you 
> should not depend on any particular environment variable(s) being set.  So 
> there should be graceful (and correct) behaviour for the case where 
> $JAVA_HOME is undefined.
> 
> Ben. :)
> 
> bab@espresso:~> kaffe -version
> Kaffe Virtual Machine
> Copyright (c) 1996-2000
> Transvirtual Technologies, Inc.  All rights reserved
> Engine: Just-in-time v3   Version: 1.0.6   Java Version: 1.1
> bab@espresso:~> java -version
> java version "1.3.1"
> Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-FCS)
> Java HotSpot(TM) Client VM (build Blackdown-1.3.1-FCS, mixed mode)
> bab@espresso:~> orp -version
> Open Runtime Platform, version 1.0.5
> bab@espresso:~> gij -version
> gij (GNU libgcj) version 0.0.7
>  
> Copyright (C) 2001 Free Software Foundation.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:



Reply to: