Dmitry,
I support your idea to clean up VM properties code. I do not like the
current state of the implementation too.

But I have a couple of questions:

1) Who is responsible to deallocate memory for hidden properties? E.g. the
same "const char*"  value could be allocated with malloc or new or could be
the static value.

2) By adding hidden properties you introduce a new style of communication
between components. Why limit hidden properties with "const char*" values?
Are there any problems with void* ?


On 10/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:

Inline

Dmitry Yershov wrote:

[snip]
>
>                        VM properties proposal
>                        ======================
>
>     The general purpose of VM Properties subcomponent is to provide
> centralized access to a common properties table. A property is meant
> as a pair of <key> and <value>. The properties stored in VM Properties
> table represent configuration settings for a separate component (such
> as VMCore, GC, JIT etc) or for the whole system. Another use case for
> the properties is communication between different components.
>
>                             Requirements
>                             ============
>
>     1) The <key> and <value> are represented as string (i.e. char*).

and I propose that on each operation, a copy is made, so that the caller
   frees the  string that they got or gave.

>     2) NULL values are allowed.
>     3) VM Properties subcomponent exports its interface as part of VM
>        Core.
>     4) There are two kind of properties
>           * Public properties are properties visible both to all VM
>             components and to Java applications (by means of
>             java.lang.System.getProperties() method).
>           * Hidden properties are used for VM components communication
>             only, not accessible from Java side.
>     5) There is a way to set hidden properties through non standard
>        command line option (   -XDefine<key>=<value>).
>     6) There is a way to get a list of defined properties which keys
>        begin with a particular prefix.
>     7) Properties table should be thread safe.
>
>                       VM Properties usage scenario
>                       ============================
>
>     Components can define properties and lookup them by name. When
> setting the property it can be marked either public or hidden. A
> property should be marked as hidden if it is intended internal usage
> only. Public properties are supposed to be visible from Java side also.
> In the same time it is possible to obtain a list of all public
properties
> to pass them to Java side.
>
>                        Defined Interface functions
>                        ===========================
>
>     void set_property(const char * key, const char * value) - Sets the
>     public property. NULL values are supported.
>
>     void set_hidden_property(const char * key, const char * value) -
Sets
>     the hidden property. NULL values are supported.
>
>     const char * get_property(const char * key) - Returns the value of
the
>     property if it has been set by set_property function. Otherwise
returns
>     NULL.
>
>     const char * get_hidden_property(const char * key) - Returns the
value
>     of the property if it has been set by set_hidden_property function.
>     Otherwise returns NULL.
>
>     bool is_property_set(const char * key, bool hidden) - Checks if the
>     property is set.
>
>     void unset_property(const char * key, bool hidden) - Unsets the
property.
>
>     char * * get_public_property_keys() - Returns an array of keys for
all
>     public properties set.
>
>     char * * get_properties_staring_with(const char * prefix, bool
hidden) -
>     Returns an array of keys for all properties set whose keys start
with
>     the prefix specified.

1) if this is a C++ class, lets drop the word 'property'
2) Don't hardcode 'hidden' into the API, as we may have other types down
the road.  Make it an argument

   set( key, val, type )
   get( key, type )
   is_set(key)
   unset(key)
   get_keys(type)
   ....

>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Mikhail Fursov

Reply via email to