harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib][beans] Current java6 bean implementation does not persist some class properly [was: There are some JDK 6 feature not implemented]
Date Thu, 05 Jul 2007 10:02:35 GMT
Paulex,

> But I think the
> persistent delegate mechanism are very similar with serialization, on which
> we need to be compatible with other Java SE implementation, so it makes
> sense to make them the API tests which pass on RI. Did I miss something?

Yes, we need to be compatible with other implementations when we are
talking about public API. We also should be able to read files
produced by XMLEncoders from other implementations and do our best to
make sure our XMLEncoder produces valid artifacts that can be red by
other XMLDecoders.

At the same time I don't see any problems with having implementation
specific tests. They  check the behavior of our persistence delegates
directly via calling their protected methods and without dealing with
complex logic of (XML)Encoder / (XML)Decoder. And they won't pass on
RI at least because RI uses other class names for its persistence
delegates. My understanding is that we should not try to enable these
tests on RI since IMO this kind of efforts could be treated as a
reverse engineering of internal RI classes.

On the other hand, we can test persistence delegates logic indirectly
using (XML)Encoder / (XML)Decoder. And we have a lot of this kind of
tests in XMLEncoderTest and XMLDecoderTest. These tests are API tests
indeed and IMO should be enabled on RI as well as on Harmony.

With Best Regards,

2007/7/5, Yang Paulex <paulex.yang@gmail.com>:
> 2007/7/4, Alexei Zakharov <alexei.zakharov@gmail.com>:
> >
> > Spark Chen wrote:
> > > > If no objection, I will go to implement those missing persistence
> > > > functionality.
> >
> > FYI we already have number of persistence delegates classes located in
> > org.apache.harmony.beans package, and FieldPersistenceDelegate is one
> > of them. It contains the algorithm that is very close to one you've
> > implemented in the patch for HARMONY-4321. So I don't think we should
> > add new FieldPersistenceDelegate, let's fix the existing one instead
> > (if it needs fixing). BTW, we also have a special folder
> > (src/test/java-internal/org/apache/harmony/beans) where tests for
> > persistence delegates are located. Shouldn't we create something like
> > FieldPersistenceDelegateTest there?
>
>
> Seems the tests in src/test/java-internal/org/apache/harmony/beans are
> implementation tests, all of which fail on RI with message like "
> java.lang.NoClassDefFoundError:
> org/apache/harmony/beans/ArrayPersistenceDelegate ". But I think the
> persistent delegate mechanism are very similar with serialization, on which
> we need to be compatible with other Java SE implementation, so it makes
> sense to make them the API tests which pass on RI. Did I miss something?
>
> Thanks,
> >
> > 2007/7/3, Tony Wu <wuyuehao@gmail.com>:
> > > On 7/3/07, Spark Shen <smallsmallorgan@gmail.com> wrote:
> > > > I find beans.XMLEncoder does not persist java.lang.reflect.Fieldproperly.
> > > > And I suspect there are more classes not properly handled.
> > > >
> > >
> > > Yes, I think so.
> > > > I have reported a JIRA:
> > > > https://issues.apache.org/jira/browse/HARMONY-4321
> > > >
> > > > If no objection, I will go to implement those missing persistence
> > > > functionality.


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message