harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [vmi] Retrieving system properties
Date Thu, 14 Dec 2006 20:27:49 GMT


Oliver Deakin wrote:
> Alexey Varlamov wrote:
>> 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:" ?).
>>
> 
> (Re: mailer bug - possibly, I see them split out of the thread as well, 
> but with
> the correct "Re:" mail subject. Annoying because it breaks up the flow 
> of the
> thread, and responses are easily missed/lost.)
> 
>> So I believe we have true agreement here.
> 
> Great! Geir, does this answer your question?

It answers the question above, but didn't answer my earlier question (I 
think I asked, of why *not* to have (key, NULL)?  The impl of 
System.getProperty() can enforce the API of System.getProperty(), but if 
we find it useful as a general facility in the VMI, why not?

The only reason I can think of is to avoid the extra NULL check (in 
Java), but you have to look at the result code anyway when using 
GetSystemProp(), right?

geir



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


Mime
View raw message