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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
