harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [drlvm] Illegal command line options
Date Mon, 19 Feb 2007 11:11:35 GMT
Agreed - I would suggest that we work within the spec here, at least as 
far as the RI does.

Regards,
Oliver

Tim Ellison wrote:
> 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
>>>
>>>
>>>       
>
>   

-- 
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