Re: [vmi] Retrieving system properties (was: Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM)

[Geir Magnusson Jr.]

If that's all they are used for - the native interface to the same 
thing, then fine.

But then write that down too in the comments that this is simply that...
geir


Alexey Varlamov wrote:
2006/12/14, Geir Magnusson Jr. <[EMAIL PROTECTED]>:


Alexey Varlamov wrote:
> 2006/12/13, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>>
>>
>> Gregory Shimansky wrote:
>> > Alexey Varlamov wrote:
>> >> 2006/12/13, Gregory Shimansky <[EMAIL PROTECTED]>:
>> >>> Tim Ellison wrote:
>> >>> > Alexey Varlamov wrote:
>> >>> >> Is there any reason to distinguish these cases? I suppose 
no, then
>> >>> >> returned NULL is fine.
>> >>> >
>> >>> > 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?
>> >>
>> >> Some properties may act as a flag, e.g. 
-Djava.lang.SecurityManager.
>> >> However, they have empty value in RI (interestingly, DRLVM ignores
>> >> such arguments - must be a bug). So NULL value is still enough to
>> >> indicate no such property is set.
>> >
>> > I don't see how we can distinguish such properties in drlvm using 
just
>> > one function get_property(const char*, PropertyTable). It either
>> returns
>> > a valid pointer to the property string value or NULL.
>> >
>> > Also empty value in my understanding is still a valid value "".
>>
>> yes, but NULL and "" are still two different things.  I suspect 
that we
>> should simply modify the API to have return code :
>>
>>    int status = get_property(const char* key, const char **value, 
table)
>>
>> so you can see if the key exists if you care.  You may not care.
>>
>> Or, add a new method
>>
>>   int status = has_key(char *key);
>>
>> depending on whatever criterion we use for this API.
>
> There is such API:
> VMEXPORT int is_property_set(const char* key, PropertyTable 
table_number);
> Actually, NULL property values are allowable in drlvm just
> historically, I see no strong reason to retain this.

So we have it now, and you want to take it away because of it's
similarity to a Java API?

The point is not a similarity per se, but consistency of the Java
system properties and underlying VM properties. I may miss the point
behind the VMI facilities for system properties, but in my
understanding they are intended to backup Java properties. So this is
a standard Java<>native communication.


I'm not understanding yet what the harm is in having this facility.

geir