Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]

[Jan Schulz <default@katzien.de>]

Hallo David,

First of all: I've written up my version of this all on 
http://java.debian.net/index.php/CombinedClasspathAndRuntimeSolution

Please comment, I'm not sure, how well I've written that up...

* David Walluck wrote:
>Jan Schulz wrote:
>So far, this is the only options we use:
>$JAVACMD $FLAGS -classpath $CLASSPATH $OPTIONS $MAIN_CLASS "$@"

AFAIK, you also do a symlinking for each JVM.

>I must admit to not understanding much about the connection between 
>-bootclasspath, -classpath, and -extdirs even after reading the Sun 
>documentation, but if it makes sense, then all three could be used.

Hm, AFAIk, the bootclasspath is inserted before teh classpath in the
searchpath for the classloader. extdirs wil AFAIK do the same. The
order in the end is
bootclasspath/extdir -> classes, which come with the JVM -> classpath
This will allow to overwrite parts of the classes, which come with the
JVM.


>But of course, free jvm's may support none of these options, so where's 
>the other layer that would handle converting between the two? Is `java', 
>`javac' and/or 'javadoc' supposed to be wraper scripts themselves?

I'm not sure, what /usr/bin/java should be. It shouldn't be used in
pacakaging (can be anything, so it will break in some cases). To make
it most usefull, it should be a wrapper script around the
'finding a working runtime' code, using a internal list of JVMs,
sorted by some sensible preference.

>>difference is, that I propose to add had dependecies (package manager
>>level) and your scritp does it automagically, when jars are installed,
>>right?
>I don't understand what you mean here.

You assume, that all JVM will be able to work. I assume that non will
and the packagers should add the ones, which do. The first is fine in
sytems, where only sun-derived JVM are in, but will break to much, if
free implementations come into the game. IMO...

Another thing is, that AFAIK, your 'symlinking' will add any jar to a
JVM classpath, but teh JVM does not Depedn on it (that's how i
understood your system of 'adding API to older JVMs). I propose thgat
this is also done, but in a mre controeld way and on runtime (without
symlinks)

>1.) The first is not picking up dependencicies for a given jar file 
>(i.e., what could usually be found in a jar's Class-Path in the 
>manifest). You propose flat files for each jar.

Yep, see the wiki for the proposal.

>I think symlinks offer 
>more over and are easier to update than sed and grep on a file, but 
>whatever, the important thing is that we both want this solved.

Hm, you can't symlink to multiple files. grep and sed ar eindeed not
really performant, but its teh best I can do :) Perl or python code
welcome, but I haven't learned that languages yet.

>2.) The second is not providing enough virtual provides. Take 
>jdbc-stdext-ext again as an example. This is only needed by pre 1.4 
>jvm's, but the 1.4 jvm's don't have a virtual provides for this package. 
>Similarly, we have a virtual provides for jaxp_parser_impl provided by 
>crimson, xerces-j2, etc., but the 1.4 jvm's don't have a virtual 
>provides for this either. At one time it was decided not to do this 
>because xerces was better, but in this case, I think the correct 
>solution would have been to let update-alternatives handle it (where 
>xerces-j2 would get the highest priority) but definitely xerces-j2 
>should not be required with a 1.4 jvm.

This is also in the proposal, by adding the Classpath elements to the
'flat file' of the JVM, which will then be rmeoved from the "requested"
classpath, when the classpath is build.

>We may have already done some of this in the java-functions script 
>(which is about 300 lines). You seem to want to do a complete rewrite 
>and maybe this is in order, but I don't know.

Gentoo has one, I have done one. When I looked at gentoos, I found
that they have done much the same as I have :) I haven't seen yours,
though. 

Now we need to do one right :)

>Exactly (wrt the dual functions/startup wrapper idea). But if you don't 
>plan on using /bin/sh, what do you plan on doing with the output string?

Hm, adding it to System.exec() or a C exec or a perl one? :) 

>We may want to use something akin to /etc/lsb-release when we have such 
>standard functionality in place.

Whats that?

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."