Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexey.v.varlamov@gmail.com
 designates 64.233.162.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=IbJywAfXR2Rp1J5gUyAe54zHPgzVlghecdmcnsjwUDNWJ6X5pj0U4+kZTihaWpne+cWRt8cyYQHPHszi/MdF9a+qHf+FVuSvN3S3rWHpr9zrm/GKpJ8g5VIazZ6ZQijyPBWD+2hoiOFvWiGHuxqqnlWdmruu5sBYYsbOZuOeNtM=
Message-ID: <f944d83d0612140332wefcd2afw2eee77581f665b01@mail.gmail.com>
Date: Thu, 14 Dec 2006 17:32:43 +0600
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [vmi] Retrieving system properties
In-Reply-To: <45813475.1090306@googlemail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6e47b64f0612122227p9371022h3e98701c8caf2d82@mail.gmail.com>
	 <457FEF68.7000602@gmail.com> <eloum4$iir$3@sea.gmane.org>
	 <45800501.4080208@gmail.com> <elp12d$upt$1@sea.gmane.org>
	 <458019CD.7040406@gmail.com> <45811093.9010709@pobox.com>
	 <f944d83d0612140154l1a99ff44m49ce18c313da312d@mail.gmail.com>
	 <45812313.6030601@pobox.com> <45813475.1090306@googlemail.com>

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
>
>