Hi Rachna,
Updated the webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.01/
Regards,
Dora
On 2019/1/4 17:44, Rachna Goel wrote:
Hi Dora,
Kindly update copyright years in both files and add bug id in
LocaleProvidersRun.java.
Other than that, it looks good to me.
Thanks,
Rachna
Objects.equals is not type-safe:
Objects.equals(1, "your mom"); // returns false
Comparator.equal(1, "your mom"); // error
However, I agree that they are both slower than Float.equal(float, float)
and Double.equal(double, double).
пн, 7 янв. 2019 г. в 01:41, <
Followers of Project Valhalla will see that this issue comes up when
defining equality on value types. The relation you are looking for is
being called "substitutible"; it asks whether there is any way to
distinguish between two values. For primitives other than float/double,
this coincides
FYI, the comment about compatibility was obsoleted by the addition of
default methods in Java 8.
On 1/4/2019 6:34 PM, some-java-user-99206970363698485...@vodafonemail.de
wrote:
The methods currently provided by the Map interface
(https://docs.oracle.com/javase/8/docs/api/java/util/Map.html)
My main goal was to provide a way where NaN is equal to NaN and I went with the
behavior of the
respective wrapper classes, Float and Double, which consider -0.0 and +0.0 as
not equal.
The static method could be called "exactlyEquals" if that is better.
It might also depend on the usecase
If the developer implemented the Comparable interface correctly, the method you
proposed would be
equivalent to java.util.Objects.equals(Object, Object).
Additionally both variants would require boxing for primitive types which I
initially wanted to prevent.
> Zheka Kozlov hat am 6. Januar
Why don't we just add a generic method which compares any instances of
Comparable?
public interface Comparator {
...
public static > boolean equal(T x, T y) {
return x.compareTo(y) == 0;
}
}
Usage:
Comparator.equal(1, 1); // true
Comparator.equal(1.0, 1.0); // true
