Hi Daniel, Your patch broke the Mauve gnu.testlet.java.io.Serializable.readResolve test. If the readResolve method is in the current class and it is private it is no longer found.
Regards, Jeroen > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Daniel Bonniot > Sent: Monday, June 27, 2005 19:32 > To: classpath-patches@gnu.org > Subject: [cp-patches] Re: Serialization: readResolve and > writeReplace inparent class > > > This seems like it must be duplicated somewhere, but I couldn't find > > it quickly. > > I also looked but could not find code to reuse. > > > There is getPackagePortion in Class, maybe making that > > package-private and then using it would be good. > > We're in java.io... > > I wouldn't mind adding a utility method somewhere if I'm > pointed to the right > place. On irc, Tom seemed to think it's trivial enough to not bother. > > > GNU style is to put line breaks before operators, not after them. > > OK, fixed, I reattach the patch. > > > I wonder if there is a strange case here where someone adds > a private > > method to the class hierarchy "later" (after all the other > classes are > > compiled). Should the private method hide the superclass methods of > > the same signature? Perhaps this is an incompatible > change, offhand I > > forget. > > I don't know the answer. If somebody can come up with a mauve test... > > In the mean time, my patch improves on the current behavior. > > Daniel > _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches