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: [vmi] Retrieving system properties
Date Thu, 14 Dec 2006 11:32:43 GMT
2006/12/14, Oliver Deakin <oliver.deakin@googlemail.com>:
> Geir Magnusson Jr. wrote:
> >
> >
> > Alexey Varlamov wrote:
> >> 2006/12/14, Geir Magnusson Jr. <geir@pobox.com>:
> >>>
> >>>
> >>> Tim Ellison wrote:
> >>> > Gregory Shimansky wrote:
> >>> >> Tim Ellison wrote:
> >>> >>> Gregory Shimansky wrote:
> >>> >>>> Tim Ellison wrote:
> >>> >>>>> Maybe we do, i.e. where there is no value "-Dfoobar".
 So
> >>> perhaps we
> >>> >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE
and
> >>> sets the
> >>> >>>>> the *valuePtr to NULL if there is no value; and returns
a
> >>> >>>>> VMI_ERROR_NOT_FOUND if the property is undefined.
> >>> >>>> Now I am confused. What is the difference between a property
> >>> which has
> >>> >>>> no value and an undefined property?
> >>> >>> Sorry, I meant a property whose value is NULL.  So the three
> >>> cases are:
> >>> >>>
> >>> >>> 1) key = "foo", value = "bar"
> >>> >>> 2) key = "foo", value = NULL
> >>> >>> 3) no key called "foo"
> >>> >>>
> >>> >>> If (2) is disallowed then we should document that in
> >>> SetSystemProperty().
> >>> >> I would prefer to have (2) to be illegal. Can we document this
> >>> please?
> >>> >
> >>> > No objection here.  So to attempt a new clarification ...
> >>> >
> >>> > GetSystemProperty will return VMI_ERROR_NONE and a string value for
> >>> > existing properties, or NULL value for a non-existent property.
> >>> >
> >>> > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and
> >>> > SetSystemProperty will return VMI_ERROR_NONE for setting an existing
> >>> > property to a string value, or VMI_ILLEGAL_ARG if there is an
> >>> attempt to
> >>> > set the property value to NULL.
> >>> >
> >>> > How does that sound?
> >>>
> >>> Why again do we want 2 to be illegal?  (Sorry, was out of pocket for a
> >>> while there yesterday...)
> >>
> >> This is aligned with the API specification for
> >> j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for
> >> both keys and values.
> >
> > Why do I care about the Java API here?
> >
>
> I think we need to here since we're talking about properties that are
> accessible from Java. Do we want to be able to set a property that is
> accessible from Java to a value that is invalid by the Java API? If someone
> calls System.getProperty() on a key that has NULL value, what do we return?
> Do we benefit from allowing NULL values?
>
> My personal feeling is that we should follow the Java API here, since
> we're changing Java properties.

Exactly! I said very same thing in parallel thread (BTW is it a bug of
some mailer - reply going to a new thread with "Re:" ?).

So I believe we have true agreement here.

>
> Regards,
> Oliver
>
> > geir
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>

Mime
View raw message