Bug#212863: finjava: a tentative summary
Hello Daniel,
Wednesday, October 8, 2003, 12:11:24 PM, you wrote:
> There seems to be some misunderstanding going on. Having not taken
> sides, I thought I would try to help clarify the positions.
Thanks for summarizing it up!
> 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.
IMO, and after having alook at sablevm, kaffe and gij during teh
discussion: all of them are compatible enough to be used in the
normal sense:
export CLASSPATH
-> will result in a classpath, setup from basic classes and the
added ones.
JAVACMD Mainclass options
IMO the only switch, which needs additional specification would be
'-classpath' to include the runtime environment by default. I
remember kaffe not setting it, but I think Ean made sure it is
included during the 1.1 update.
> This is already done by the wrapper scripts. So findjava should not
> return the 'raw' binary, but the wrapper scripts (ie
> /usr/bin/gij-wrapper, not /usr/bin/gij).
findjava will return, what is specified. I really hope that gij and
sablevm will add a java-config file for their wqrappers and not for
the main app.
> One thing needed is to put such a (minimal) standard of command-line
> arguments in the Java policy, so JVM packagers not what to implement.
> I'm not sure if we got there yet.
IMO we are there now. But lets see what other people thing what
needs to be included in this list. The internal (GC, jit and so on)
are handled by findjava, debuging options are better handled on a
per JVM basis as well and this should probably be done via either a
findjava switch or a via using 'OVERWRITE_VM_COMMAND' (or whatever
it was...), so you exactly know which VM is called. So the only
uscase is starting a app and there it's enough to use CLASSPATH and
the main class.
> Ean wrote:
Nope, me wrote that :)
> It's true that we cannot handle every option. But we can handle them
> progressively as the need appears. Whether or not Sun should do it,
Yes, also true, but IMO just *now* there isn't any other situation,
which isn't handled by teh wrapper scripts and all other commands.
> nothing prevents us from making our own standard if needed (ie if "Sun
> compatible" is not enough).
^^^^^^^^^^
:) Sun isn't compatible to each release, which I learned during the
discussion and why I had to stop using teh alternative system
altogether...
> between JVM callers and JVMs. For Sun JVM, the mpkg-j2sdk could install
> our own wrapper if necessary.
True, but very confusing...
> I hope I represented well the opinions (obviously, complain if not) and
> that will help understanding the situation.
I think you summariesed it really well! Thanks!
Jan
Reply to: