2007/7/5, Alexei Zakharov <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: > 2007/7/4, Alexei Zakharov <[EMAIL PROTECTED]>: > > > > 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 <[EMAIL PROTECTED]>: > > > On 7/3/07, Spark Shen <[EMAIL PROTECTED]> 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
