RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects
forax at univ-mlv.fr
Sat Nov 16 10:23:46 UTC 2013
On 11/15/2013 10:04 PM, John Rose wrote:
> On Nov 14, 2013, at 7:21 PM, Joseph Darcy <joe.darcy at oracle.com> wrote:
>> Catching up on email, the specification of java.lang.Class does not explicitly promise that its notion of equality must be identity for all time. Therefore, while not required for today's implementations, I would prefer that new code we write in the JDK use equals rather than == when comparing classes.
> There's no possible future where java.lang.Class would return true for equals but false for == (acmp). So there's no future-proofing to do here.
> Reification of generics might require something like this, but we could not break class identity without (as others have pointed out) breaking compatibility with a huge amount of code "in the wild".
> Before that would happen, we would introduce a new auxiliary type (e.g., java.lang.Species and java.lang.Object::getSpecies) that would represent the richer view of an object's runtime type.
> I do hope, in a future release, to "hack" reference equality, but in a different direction, allowing == (acmp) to return true *more often*, not allowing it to return *less often*. The point will be to align the semantics of equals and acmp *more* closely for some types, notably the wrappers and java.lang.String. (Interned referneces are so last-century.)
> — John
I think I prefer Variety to Species to get ride of the ambiguous plural.
More information about the core-libs-dev