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 (was: Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM)
Date Thu, 14 Dec 2006 20:41:01 GMT
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. <geir@pobox.com>:
>>
>>
>> Alexey Varlamov wrote:
>> > 2006/12/13, Geir Magnusson Jr. <geir@pobox.com>:
>> >>
>> >>
>> >> Gregory Shimansky wrote:
>> >> > Alexey Varlamov wrote:
>> >> >> 2006/12/13, Gregory Shimansky <gshimansky@gmail.com>:
>> >> >>> 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
>>


Mime
View raw message