harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm] Illegal command line options
Date Mon, 19 Feb 2007 09:47:51 GMT
While I agree we would not complain if a VM chooses to recognize options
disallowed by the spec, I don't think we should _require_ such behaviour
to work well with Harmony.

Regards,
Tim

Alexey Varlamov wrote:
> Aha, this investigation made the picture clearer, thanks.
> I suggest that the launcher does not care about options and just pass
> them through to VM,
> except -version/-showversion as we already discussed.
> Regarding -help, I suppose VM have smth to say beyond launcher's
> knowledge, e.g. list of options supported by the particular VM. It is
> possible to handle this similarly to -version, i.e. to settle a
> property by which VM would provide help text, but not sure this is
> really appropriate way.
> Therefore it is pure responsibility of VM to follow the spec and to
> which extent violate it :).
> To my feeling this is either outdated piece of doc or simply a
> flaw/bug in the spec; such limitation is hardly practical :(
> 
> -- 
> Alexey
> 
> 2007/2/16, Oliver Deakin <oliver.deakin@googlemail.com>:
>> 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/%3c4507F21A.8090308@pobox.com%3e*
>>
>>
>>
>> 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 <oliver.deakin@googlemail.com>:
>> >> 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
>>
>>
> 

Mime
View raw message