Where is $JAVA_HOME/lib ?

jim · External Since: Aug 29, 2005 Posts: 9

I have a java application [0] that runs fine x86 linux with sun java,
but I would like to run this on sparc linux where there is no sun java Sad

So I would like to try using debian/unstable java-gcj-compat

The application is in csi.jar and is launched from command line or from
the web browser and requires files to be placed as follows

$JAVA_HOME/lib/ext/csi.jar
$JAVA_HOME/lib/security/local_policy.jar
$JAVA_HOME/lib/security/jce1_2_2.jar
$JAVA_HOME/lib/security/US_export_policy.jar

The application starts from the browser or directly by:
$JAVA_HOME/bin/java au.gov.bafcsi.clapi.crypto.CsiManager

Can this work with java-gcj-compat?

What would be the proper location for the files? I have:
/etc/java/security
/usr/share/xulrunner/chrome/en-US/locale/en-US/global/security
/usr/share/iceweasel/chrome/en-US/locale/en-US/global/security
/usr/include/c++/4.1.2/java/security
/usr/include/c++/4.1.2/javax/security
/usr/include/c++/4.1.2/gnu/java/security
/usr/include/c++/4.1.2/gnu/javax/security
/usr/include/security
/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/security
/usr/lib/security

jim@sun:~$ java GetJVMInfo
java.version= 1.4.2
java.vendor= Free Software Foundation, Inc.
java.home= /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre
gnu.classpath.home=/usr
gnu.classpath.home.url=file:///usr/lib/../lib

any hints would be appreciated..

thanks
jim

[0] http://csi.business.gov.au/CSI/CsiInstallForLinux.tar.gz

--
To UNSUBSCRIBE, email to debian-java-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Arnaud Vandyck · External Since: Oct 30, 2006 Posts: 66

On 5/8/07, jim <jim.TakeThisOut@amarooas.com.au> wrote:
[...]
> The application starts from the browser or directly by:
> $JAVA_HOME/bin/java au.gov.bafcsi.clapi.crypto.CsiManager
>
> Can this work with java-gcj-compat?

I don't know Wink

> What would be the proper location for the files? I have:
[...]
> /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/security

This one seems appropriate but I don't know the program. Maybe other
users/devs have advices or comments?

Note that you'll have to reinstall your files when you upgrade java-gcj-compat.

--
Arnaud Vandyck

--
To UNSUBSCRIBE, email to debian-java-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Blackwell · External Since: Apr 30, 2006 Posts: 8

Arnaud Vandyck wrote:
> On 5/8/07, jim <jim DeleteThis @amarooas.com.au> wrote:
> [...]
>> The application starts from the browser or directly by:
>> $JAVA_HOME/bin/java au.gov.bafcsi.clapi.crypto.CsiManager
>>
>> Can this work with java-gcj-compat?
>
> I don't know Wink

>
>> What would be the proper location for the files? I have:
> [...]
>> /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/security
>
> This one seems appropriate but I don't know the program. Maybe other
> users/devs have advices or comments?
>
> Note that you'll have to reinstall your files when you upgrade
> java-gcj-compat.
>

Arnaud, everyone,

from a Java developer's point of view the JRE must be left alone.
Nobody must be allowed to place application specific files anywhere
in the JRE folder, or in jre/lib/ext.

To provide a Java application with the jars it needs the class path
mechanism must be used via the parameters for the "java" executable,
-jar and -cp.

When using the -jar switch -cp is being ignored and the
application's (main) jar file must contain a manifest which has
Class-Path entries which tell java about the other required jars and
their (usually relative) path (in relation to the current working
directory):

java -jar myapplication.jar

When using the -cp switch all jars and folders required in the
default class path for that app must be enlisted:

java -cp .:myapplication.jar:mysql-jdbc-driver.jar
myapplication.MainClass

(Side notes: The CLASSPATH environment variable should not be used
(use -jar or -cp instead on a case by case basis), it should not be
set globally (one can argue to use CLASSPATH inside a shell session,
but for clarity and to deprecate use of CLASSPATH the -cp parameter
should be preferred) due to possible version conflicts (application
A requiring jdbc driver X version 1, application B requiring jdbc
driver X version 2, both in the class path, results are random).

For the same reason the jre/lib/ext (extension mechanism) should be
not used, esp. since it assumes backwards compatibility of the
respective extension which in reality is something the Java
world/developer just does/do not ever think about.)

Information must be provided which folders and jar files must be
included in the class path for each application, or if the -jar
parameter must be used. When invoking the application the respective
parameters must be assembled and used.

Additional parameters must be supported, such as -client, -server,
and these parameters can vary (or not exist), esp. in the non-Java
implementations, so they must be mapped respectively or running the
application should possibly be denied if the non-Java implementation
does not provide the respective functionality.

Bye bye

--
To UNSUBSCRIBE, email to debian-java-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org