Bug#212863: finjava: a tentative summary
Hello Dalibor,
Replying here, becasue I haven't seen the post from Ean.
Thursday, October 9, 2003, 7:17:19 PM, you wrote:
> the way I understood it, it has little to do with specific tunings, and
> more with giving the application packager a simple, common way to tell
> the user which VMs will work with the package, while at the same time
> giving the user some choice, and allowing him to overwrite the choice
> the packager made.
Yes, the tuning is something you get for free. I can't really
imagine tuning a java package in a way, that it becomes so VM
specific, that a 'findjava' mechnism does not anymore work. I think,
if that happens, than it's time to Depends: and use only this
'one-and-only' VM. Or use different starter classes in different
packages.
On the other hand, I will try to extent the findjava command with
all interesting options you might find valuable to add. As I already
said, I can imagine a '--mem128' command to allocate 128MB of
memory (would be mapped by the sun VMs to '-Xm128m' IIRC).
> For example, it seems to be impossible for a non-root user, to overwrite
> the java alternative, whereas the proposed scheme allows the user to
> specify a different (maybe even working ;) jvm that he one that comes up
> on top of the alternative system.
There are two systems: one to use a 'preferred VM', which is used,
*if* possible. And there is a 'overwrite' mechanism, which is
described as 'testing only' in the manpage.
>> For instance, if the Tomcat maintainer decides that compiling certain
>> baseline classes with GCJ before running the main system with GIJ is a
>> good idea then I can't see that findjava will elegantly accomodate that.
This would result in a native tomcat, which would not use a 'java
bytecode interpreter', but would be a normal app under normal debian
policy. And not under the debian policy for java "bytecode" apps.
> Wouldn't specifying gij as the only VM in the findjava setup file that
> can run the gcj-ed tomcat be enough? You certainly wouldn't want to
> recompile tomcat with gcj on every invocation? ;)
No, that would result in errors, when the user specifys a 'overwrite
VM'. Compiled to native *must* AFAIK run with gcj and not with any
other java VM.
>>>That's Ean's point. Each JVM has its own command line arguments, so code
>>>is needed to translate a standardized set of command line arguments to
>>>the JVM own format. We should not put this translation code in a common
>>>package, because then each maintainer will need to update it from time
>>>to time, and it will be a mess.
>> Yes. That is where I'm at.
> Could the findjava script then be split apart into VM specific 'plugins'
> to do the work? then the VM package maintainers could independently
> update 'findjava-kaffe' from 'findjava-sablevm', while keeping the
> calling interface for the main 'findjava' script.
IMO, the findjava mecanism already does this: You can specify
certain internal things via a variable in the java-config-file,
which is in turn read, when findjava is called with certain options.
For example, this here might end up in a JVM, optimised for server
use and allocate 128MB of Heap [please note: the mem thing isn't
yet implemented!]:
findjava --server --mem128 ibm-java-1.4 sun-java-1.4 kaffe
It will try to find the best VM available and try to optimise it.
The java-config-file for sun-java-1.4 might look like this:
JAVACMD="/usr/lib/j2sdk1.4/bin/java"
SERVER="-server"
CLIENT="-client"
MEM128="-Xm128m" # don't remember what the right options was...
MEM256="-Xm256m"
Resulting in a outputted command like
/usr/lib/j2sdk1.4/bin/java -server -Xm128m
Dalibor might add the kaffe equivalent...
Jan
Reply to: