This is the mail archive of the
mailing list for the Java project.
Re: java.net: Classpath vs. libgcj Comparison
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: java.net: Classpath vs. libgcj Comparison
- From: "Aaron M. Renn" <arenn at urbanophile dot com>
- Date: Mon, 17 Apr 2000 20:25:00 -0500
- Cc: gs <gs at sevenmountains dot no>, Classpath <classpath at gnu dot org>, java-discuss at sourceware dot cygnus dot com
- Organization: GNU's Not Unix!
- References: <NDBBJGLBJKHIDJIDBAFAOENGCDAA.email@example.com> <38FAF077.E20C758@albatross.co.nz>
Bryce McKinlay (firstname.lastname@example.org) wrote:
> This was not actually the essential point I was trying to communicate. Rather,
> my point is that we need to choose the best features of each existing method
> and class when developing the merged implementation. Your original message
> seemed to suggest that code would be chosen on a per-class basis to become the
> merged libgcj/classpath. I pointed out the imperfections in both equals()
> implementations as an example of why this approach would be sub-optimal.
This may be true, but taking the best of each class implementation
first gets you part of the way there, and is probably the easiest thing
to start with. Picking different method implementations from
different class implementations is trickier because of possible
unforseen side effects, but is something we will certainly want to do.
That's why I stressed that any merging effort I undertook would be
subject to further improvements.
Aaron M. Renn (email@example.com) http://www.urbanophile.com/arenn/