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 alexei.zakharov@gmail.com
 designates 64.233.166.180 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=A3tibifB7ai7Ub3C3d/CP6Aui1/iP8yv838ggHTXs15SC0W4v97gvSxejfagTi+0rbPG9YIGd2vLxz5kACNabCwrpGU4Qsb2n1QzDjR6egeQjVEvYe+z+Mx/XSIj7L+D9XeoCWTgn8la6oRtHCQFh7CHxpTjpI/02cTGr9CMpXA=
Message-ID: <2c9597b90606140736l2ddd8057i5ea71ba8108857b4@mail.gmail.com>
Date: Wed, 14 Jun 2006 18:36:00 +0400
From: "Alexei Zakharov" <alexei.zakharov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] [testing] java.beans tests
In-Reply-To: <44900BB5.9090505@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2c9597b90606140526r2fa2ea9bpaf6199a7dd1dea03@mail.gmail.com>
	 <44900BB5.9090505@gmail.com>

Mikhail, Tim,

> I suggest that you raise a few examples here.

The first example that comes to my mind is the RI's implementation of
PersistenceDelegate for java.lang.String class. (Persistence delegate
is a class that manages persistence details of his target class and is
used by java.beans.XMLEncoder). RI's imeplementation just does nothing
and returns null there applicable. It seems that RI guys simply
created a stub class they do not actually use. Most likely they
embedded String-handling logic in some other place in code. IMHO such
a decision doesn't fully correspond the idea of persistence delegates
as a place for persistence-handling logic.

BTW, our StringPersistenceDelegateTest (point 2 in my classification)
also expects some non-stub behavior from StringPersistenceDelegate. It
seems that people who have created this test also don't like this
aspect of the RI's implementation. :)

2006/6/14, Tim Ellison <t.p.ellison@gmail.com>:
> Alexei Zakharov wrote:
> > Hello to everyone,
> >
> > I am currently investigating tests for java.beans module.
>
> Great.
>
> > As far as I
> > understand there were two separate contributions of java.beans tests
> > from two different parties. And these contributions were merged into
> > the single combined test suite we have now in svn. As a result
> > currently we have about 400 test case failures (excluded) out of
> > approximately 1200. After spending some time on this I realize that we
> > have two types of issues here:
> >
> > 1. Test checks the compliance with very deep detail of RI's behavior (that
> > is not in spec).
> > 2. Test expects the behavior that differs from the RI's behavior as well as
> > from our implementation's behavior.
> >
> > As for point 1, I'm unsure here. Do we really need to be completely
> > identical to the RI in terms of public methods behavior? Some RI
> > decisions are strange.
>
> We need to work the same (possibly unspecified) way as the reference
> implementation to ensure compatibility for Java apps.  An example of
> some areas we already thought about are listed here [1].
>
> If the decision is strange so that you think it is bug then we may
> choose to depart from the RI's behavior after discussion on this list,
> but if it is wrong because you disagree with the approach, then I'm
> afraid that compatibility wins <g>.  I suggest that you raise a few
> examples here.
>
> > For point 2, I believe we should rewrite or delete such tests.
>
> Agreed -- please indicate with your JIRA patch why you think they are
> wrong, and that will help people review you rewrite/deletion request.
>
> > Thoughts, suggestions?
>
> I'm happy that you are looking into this, and look forward to your patches!
>
> Regards,
> Tim

-- 
Alexei Zakharov,
Intel Middleware Product Division

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