harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@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:24:36 GMT
2007/7/5, Alexei Zakharov <alexei.zakharov@gmail.com>:
>
> 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.


Agreed.

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.


Agreed, sorry if I made confusion here, my point is API tests is necessary
especially on compatibility, and of course if the implementation specific
test can help to improve the coverage and then Harmony implementation
quality, there's no reason not to welcome :).

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.


Glad to hear this, thanks

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
>



-- 
Paulex Yang
China Software Development laboratory
IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message