Joe Darcy wrote:
Martin Buchholz wrote:
On Wed, Sep 9, 2009 at 17:34, Joe Darcy<joe.da...@sun.com> wrote:
Martin Buchholz wrote:
Google would like to contribute implementations of the methods below.
Here's a webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/
Wherever these compare methods go, into the N wrapper classes or into
java.util.Compare,
Given the precedent of Double.compare(double,double) and
Float.compare(float,float), I think the compare methods need
to go into the primitive wrapper classes.
I think the instance method compareTo should be rewritten
in terms of the new static compare. In particular,
422 public int compareTo(Short anotherShort) {
423 return this.value - anotherShort.value;
424 }
should get replaced with
422 public int compareTo(Short anotherShort) {
423 return compare(this.value, anotherShort.value);
424 }
As you wish.
Webrev updated.
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/
I approve these changes in an engineering sense; they are a fix for bug
6582946 Add suite of compare(T, T) methods for ints, longs etc
This consolidates the comparison logic in a single method per type and
reuses the existing implementation tests.
(Later in JDK 7, a set of "unsignedCompare" methods are possible
additions
to the platform too.)
We have tests (not yet included) but they would need to be
jtreg-ified.
Is there any junit support yet for jtreg?
No.
Once the home of the new methods is determined, I'll file a ccc
request so
these changes can go back after any additional testing is settled.
There's not a whole lot of testing work here, but we will provide it if
it CCC is approved.
I've created a ccc for this and will let you know when it is approved.
-Joe
Martin,
The paperwork has been handled; I approve your set of compare methods
going back.
Thanks,
-Joe
