I would suggest we follow the RI where possible with these options.
Using my simple launcher again, I tried passing some of the options you
mentioned to the RI via CreateJavaVM:
-client/-server result in errors. -Xclient and -Xserver are also
unrecognised. Im guessing the RI launcher converts these options to
something else before passing them in, but I have no idea what.
-agentlib/-agentpath/-ea/-da/-esa/-dsa - These all appear to be
accepted by the RI, in violation of the spec. I think we're ok to follow
the RI here and just accept them.
-help/-? result in errors, but this does not surprise me - I would
have expected this help text to come from the launcher, not the VM, and
is essentially the same as typing "java" without any command line options.
-version/-showversion are both unrecognised. We have discussed these
before on the list [1], and I think Tim's suggestion of reading system
properties to construct the version information made sense. I would
suggest printing some of the standard properties (java.vm.name,
java.vm.version etc.) to create version information for whichever VM we
are using, and then also some property (hy.classlib.version?) set by
classlib during initialisation. If these properties could contain some
kind of time stamp/revision number that would be great, although I dont
know how feasible that is.
Regards,
Oliver
[1]
*http://mail-archives.apache.org/mod_mbox/harmony-dev/200609.mbox/[EMAIL PROTECTED]
Alexey Varlamov wrote:
You are right, I'm reading the same in the spec ... and this appears
to be a problem.
There is a number of standard options actualy:
-client/-server, -agentlib/-agentpath, -ea/-da/-esa/-dsa/, -help,
-version/-showversion etc
Should the launcher recognize&convert all of them? Looks somewhat
cumbersome...
Maybe just prefix any unrecognized with __(double underscore), like
-verify to __-verify.
Just easier for VM to trim such prefix and parse as standard arg :)
--
Alexey
2007/2/15, Oliver Deakin <[EMAIL PROTECTED]>:
It has come to my attention recently that DRLVM accepts the -verify
option when it is passed in through the invocation API. This actually
breaks the JNI spec rules outlined at:
http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html#wp16334
These rules are actually quite tight - if I read it correctly, it
appears that they do *not* allow the VM to interpret "-version" as an
option, and if you write a simple launcher that tries to pass -version
to the RI via CreateJavaVM you get an error:
Unrecognized option: -version
Cannot create JavaVM
The spec seems fairly clear that we should not respect these options if
they are passed through, but we can accept X prefixed versions of them.
This would require the launcher to convert these options from e.g.
-verify to -Xverify before passing them into the VM.
Thoughts?
Regards,
Oliver
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
