(small) Integer instances are cached, so the invariant x == y is holded for small instances (actually -127 +128, depends on JVM): Integer a = 10; Integer b = 10; assert(a == b); // ok, same instance reused a = 1024; b = 1024; assert(a == b); // fail, not the same instance…. assert(a.equals(b)); // … Read more
This is partly because an AtomicInteger is not a general purpose replacement for an Integer. The java.util.concurrent.atomic package summary states: Atomic classes are not general purpose replacements for java.lang.Integer and related classes. They do not define methods such as hashCode and compareTo. (Because atomic variables are expected to be mutated, they are poor choices for … Read more
Apache commons-collections has CollectionUtils#isEqualCollection: Returns true if the given Collections contain exactly the same elements with exactly the same cardinality. That is, if the cardinality of e in a is equal to the cardinality of e in b, for each element e in a or b. Which is, I think, exactly what you’re after.
I came to realize that I wanted Equals to mean two different things, depending on the context. After weighing the input here as well as here, I have settled on the following for my particular situation: I’m not overriding Equals() and GetHashCode(), but rather preserving the common but by no means ubiquitous convention that Equals() … Read more
Nice question, the surprising thing about the code above is that println “${‘test’}”.equals(‘test’) returns false. The other line of code returns the expected result, so let’s forget about that. Summary “${‘test’}”.equals(‘test’) The object that equals is called on is of type GStringImpl whereas ‘test’ is of type String, so they are not considered equal. But … Read more
The JPA 2.0 Specification states that: The entity class must have a no-arg constructor. It may have other constructors as well. The no-arg constructor must be public or protected. The entity class must a be top-level class. An enum or interface must not be designated as an entity. The entity class must not be final. … Read more
Scala 2.7 tried to add functionality to Java [] arrays, and ran into corner cases that were problematic. Scala 2.8 has declared that Array[T] is T[], but it provides wrappers and equivalents. Try the following in 2.8 (edit/note: as of RC3, GenericArray is ArraySeq–thanks to retronym for pointing this out): import scala.collection.mutable.{GenericArray=>GArray, WrappedArray=>WArray} scala> GArray(0,1,2) … Read more
Check out this article: Boxed values and equality When comparing wrapper types such as Integers, Longs or Booleans using == or !=, you’re comparing them as references, not as values. If two variables point at different objects, they will not == each other, even if the objects represent the same value. Example: Comparing different Integer … Read more
The string comparison with StringComparison.OrdinalIgnoreCase works in memory or with IEnumerable<T>. You are trying to use it with IQueryable<T>, but the provider of your queryable does not understand it. This works for me: db.Users.FirstOrDefault( s => s.Username.Equals(username, StringComparison.OrdinalIgnoreCase) );
Yes, the default implementation is Object’s (generally speaking; if you inherit from a class that redefined equals and/or hashCode, then you’ll use that implementation instead). From the documentation: equals The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this … Read more