harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] Illegal command line options
Date Tue, 20 Feb 2007 11:18:50 GMT
2007/2/19, Oliver Deakin <oliver.deakin@googlemail.com>:
> 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.

Sounds convincing. My motivation was to avoid adding extra contract
for VMs, but seems that pre-defined mapping of arguments is lesser
evil here. Then my suggestion is to add some specific enough prefix
rather than rename options. Say _org.apache.harmony.arg. ?

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