Probably this method is overridden by subclasses, there are similar examples in the classlib it's a normal practice
2006/6/16, Alexei Zakharov <[EMAIL PROTECTED]>:
> Alexei, it would be good if you point to a simple test that shows > difference in behavior, quote the spec and describe, why you think > Harmony does things right. The spec says about persistence delegates: "The PersistenceDelegate class takes the responsibility for expressing the state of an instance of a given class in terms of the methods in the class's public API". I don't like to worry the collective mind with details of black-box testing methology I use here. This is not so important. The important thing is the result: it seems RI version of StringPersistenceDelegate looks something like that: class StringPersistenceDelegate extends PersistenceDelegate { ... // Should be the main method of the persistence delegate. // Should return the internal representation of the given // java.lang.String object as a sequence of atmoic actions. protected Expression instantiate(Object obj, Encoder encoder) { return null; } } I don't belive this implementation really "express state of" java.lang.String instance. However, the target XML produced by XMLEncoder - the final result of all this activity - shows that strings are handled correctly by RI. I suppose they move String handling logic to some other place. 2006/6/15, Mikhail Loenko <[EMAIL PROTECTED]>: > Sure we need to test protected methods and fields. Moreover we need > to test private methods either via API or by other means. > > Alexei, it would be good if you point to a simple test that shows > difference in behavior, quote the spec and describe, why you think > Harmony does things right. > > Thanks, > Mikhail > > 2006/6/14, Richard Liang <[EMAIL PROTECTED]>: > > Alexei Zakharov wrote: > > > BTW, all questionable methods of PersistenceDelegate interface are > > > protected rather than public. Do we need to test it at all? > > > > > Hello Alexei, > > > > IMHO, we need to test the protected methods, which are also part of API. > > > > > 2006/6/14, Alexei Zakharov <[EMAIL PROTECTED]>: > > >> 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 <[EMAIL PROTECTED]>: > > >> > 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 > > >> > > > > > > > > > > -- > > Richard Liang > > China Software Development Lab, IBM > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexei Zakharov, Intel Middleware Product Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]