This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: java.util Classpath/libgcj merging
- To: Mark Wielaard <mark at klomp dot org>
- Subject: Re: java.util Classpath/libgcj merging
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Mon, 19 Feb 2001 11:31:08 +1300
- CC: java-patches at gcc dot gnu dot org
- References: <20010218170647.A24884@klomp.org>
Mark Wielaard wrote:
> The following patch merges some of the simpler classes from java.util with
> the Classpath versions. It removes some RCS keywords to make it simpler to
> see that the files in Classpath CVS and gcc CVS are actually the same version.
Cool, thanks. It would be cool to have something that automatically runs diff on
the classpath and libjava trees and dumps the results out to a web page or
something.
> It reindents some files so they have the same indenting as the Classpath
> versions. And it merges some simple classes, interfaces and exceptions.
> * java/util/ConcurrentModificationException.java: merge with Classpath
> * java/util/EmptyStackException.java: idem
In the past I've held off merging in Classpath's exception classes because I'm
not sure I like the way that the SerialVersionUIDs are present in all of them.
Should it be neccessary to have a SerialVersionUID in a class that doesnt have an
explicit serialized form (ie readObject and writeObject methods)? Or are we just
potentially masking serialization incompatibilies?
> OK to commit to the head/branch?
Yes, if you think the serialization issue is ok.
> Note that I currently cannot actually test these changes with gcj because
> the head seems broken on i386 and the branch seems broken on powerpc. Sigh.
Whats the problem on the branch? Has it been reported?
regards
[ bryce ]