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.239 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=nBVO7k46u1OCJ7WNBNwR7WpT/1ZORYYg4zQfD/T7Wi0XkCA24/bZDmljbl25CG2F9A+urntlgbAzBnIdhq4E3qTtP2vSeYJEjJqCrOfJvGpcHEqtO1ZP9WZxIk3SaUuqHALinxv8Zryu9mtOKHMlW92yJ7ORcbauQuqZGeohWDA=
Message-ID: <f944d83d0612130304o1d2863e2wcc4b509442974059@mail.gmail.com>
Date: Wed, 13 Dec 2006 17:04:32 +0600
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][luni] update for bootstrapClassPath causes regression
 on DRL VM
In-Reply-To: <457FD492.5080703@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>
	 <457FA29D.3050407@pobox.com>
	 <6e47b64f0612122302n44d8f031y2ea6d31f4e6780d2@mail.gmail.com>
	 <457FB48D.1080702@pobox.com> <457FCB77.2060206@gmail.com>
	 <457FD492.5080703@googlemail.com>

2006/12/13, Oliver Deakin <oliver.deakin@googlemail.com>:
> Tim Ellison wrote:
> > Geir Magnusson Jr. wrote:
> >
> >> Do we really have a problem?  Or is it something else?
> >>
> >> Last night, Gregory tested his fix, and I've build snapshots (r486417)
> >> on x86 linux/win and x86_64 linux and spot checked with apps and such,
> >> and things seem to work.
> >>
> >> I'n posting the snapshots now to ~geirm and will send a separate note
> >> for people to evaluate.
> >>
> >
> > Also catching up on mail.  I suggested (on the other thread) that we
> > need to define the return result for undefined properties, answering
> > NULL seemed reasonable, but now I look at the vmiError enum in vmi.h it
> > appears that we have already defined:
> >   "VMI_ERROR_NOT_FOUND -- The requested system property was not found"
> >
> >
>
> This surprises me slightly - I would have imagined we would want to work
> in a similar way
> to the System.getSystem() method and return NULL in the case of a
> non-existent property
> being requested. However, it appears that GetSystemProperty() is
> intended to return
> VMI_ERROR_NOT_FOUND in this case.
>
> I would say that since the function behaviour in this case has not yet
> been clearly spec'ed
> (and we have two VMs that behave differently) we should make a choice
> now about which
> return is correct and fix up the VMs. So, should we just return a NULL
> property value and
> no error code, or return VMI_ERROR_NOT_FOUND?

Is there any reason to distinguish these cases? I suppose no, then
returned NULL is fine.

--
Alexey

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