Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mark.hindess@googlemail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hmOmV+AXPZiY0uKqXEQK7+xEhwwSlpOHt4dTLkbspMpgIX8gBYhBn3XTGwQljyhEicu4XmmHe0Z3qnD3JvZtoH2lVqmM6fvrgbKMuAQ/F8NK6gbpJ6Jz9+qY0DcsFilJEFjExyETEBkAjav6qYKJfGaRGw3FWcOvrL+6JUBoB9U=
Message-ID: <fcb9f9160604130041t504ba963pa125888d610d9af3@mail.gmail.com>
Date: Thu, 13 Apr 2006 08:41:05 +0100
From: "Mark Hindess" <mark.hindess@googlemail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: matching reference implementation exception behaviour
In-Reply-To: <6e47b64f0604130033w268f6b94h38a6bbd4e34c5370@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <fcb9f9160603240900g69cb2999ob07f3d937fb79395@mail.gmail.com>
	 <764df6d50604030608i502937d3m9aca5895b0b49065@mail.gmail.com>
	 <fcb9f9160604030637s50446857x5a8cee0120f5f7b8@mail.gmail.com>
	 <44312886.7080602@gmail.com> <443AF838.6090001@pobox.com>
	 <906dd82e0604101858k78c7eabercc756826910b754f@mail.gmail.com>
	 <443B1BE5.7090805@pobox.com>
	 <906dd82e0604102010w6854002ey4cdb5bff6be325c1@mail.gmail.com>
	 <fcb9f9160604102304i2664c838x448603afbd4ae8c9@mail.gmail.com>
	 <6e47b64f0604130033w268f6b94h38a6bbd4e34c5370@mail.gmail.com>

On 4/13/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> On 4/11/06, Mark Hindess wrote:
> >
> > Based on the goal of "being least confusing to users", I'm in favour
> > of matching the behaviour rather than the spec when there is any doubt
> > - users will expect something that runs on reference jre to run on
> > harmony and fail in the same way(s).
> >
> > Based on the same goal, I also think matching 5.0 behaviour is the
> > correct thing to do. If Harmony is going to be a 5.0 implementation
> > our users will naturally expect things to behave the same way as a 5.0
> > reference implementation.
> >
> > JIRA issues should have a clear resolution/category to record these
> > decisions - and any discussion on the mailing list should be
> > summarised in the JIRA so that we can refer people to the decision.
> > And so that we can revisit them when, as Geir says, we have achieved
> > world domination.
> >
> > Incidentally, it would be good to have some input on HARMONY-266 and
> > HARMONY-315.  (I think Stepan and I are the only ones discussing them
> > and we have opposite views. ;-) See:
>
>
> Mark, as far as there are no other opinions I'd suggest to fix HARMONY-31=
5
> in case of null provider and leave this JIRA issue open for a while. What=
 do
> you think?

Sounds like a good plan.  Thanks Stepan.

Hopefully others will step up with opinions about the other two cases.

Regards,
 Mark.

> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbo=
x/%3cfcb9f9160603310453j31abfb3dj899b538e8d6e990b@mail.gmail.com%3e
> >
> > and:
> >
> >
> > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.m=
box/%3c6e47b64f0604092314k5afa9ca8ia622beee30079c59@mail.gmail.com%3e
> >
> > Regards,
> > Mark.
> >
> > On 4/11/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> > > It's not too late to think about it once again and probably revisit
> > > the decision.
> > >
> > > As I understand goal #1 is to meet needs of as many potential users a=
s
> > we can
> > > and decision to be spec incompatible in favor of new hot RI version
> > might be not
> > > the best one.
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/4/11, Geir Magnusson Jr <geir@pobox.com>:
> > > > I think that people will steadily move up in versions, and maybe mo=
st
> > > > importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
> > > >
> > > > geir
> > > >
> > > >
> > > > Mikhail Loenko wrote:
> > > > > BTW, when we were deciding that we follow RI rather then the spec=
,
> > we
> > > > > cared about breaking existing implementations. But if RI changed =
its
> > behavior
> > > > > from being compatible to the spec in 1.4 to being incompatible in
> > 1.5 then do
> > > > > we believe that existing applications more likely stick to the
> > latest
> > > > > (1.5) version?
> > > > >
> > > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1=
.5?
> > > > >
> > > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> > > > > java.security.Signature.getInstance(String,Provider) should match
> > 5.0
> > > > > reference implementations behaviour" mail thread.
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > >
> > > > > 2006/4/11, Geir Magnusson Jr <geir@pobox.com>:
> > > > >>
> > > > >> Paulex Yang wrote:
> > > > >>> Mark
> > > > >>>
> > > > >>> You just point out a serious issue ;-) . The RI is just a conce=
pt,
> > in
> > > > >>> fact we have many RIs, Sun's JDK, BEA's JDK, even different
> > versions,
> > > > >>> Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I
> > expects), and
> > > > >>> on different platforms(win32, linux32, still even more in
> > future)...In
> > > > >>> fact sometimes they have different behavior themselves, it is v=
ery
> > > > >>> reasonable that 1.5.06 fix some bugs of 1.5.0, so that some
> > different
> > > > >>> exceptions thrown(more reasonable IAE instead of NPE, for
> > example), or
> > > > >>> more seriously, different results returned... Samples are
> > available upon
> > > > >>> request:).
> > > > >> Actually, there only is one RI for any given spec, and in this
> > case, I
> > > > >> guess we judge it to be the latest version of a spec that comes
> > from
> > > > >> Sun? (The question isn't if it comes from Sun - as the spec lead=
,
> > they
> > > > >> supply the RI - but rather what version...)
> > > > >>
> > > > >> geir
> >
> > --
> > Mark Hindess <mark.hindess@googlemail.com>
> > IBM Java Technology Centre, UK.
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>


--
Mark Hindess <mark.hindess@googlemail.com>
IBM Java Technology Centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org