RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects
vitalyd at gmail.com
Fri Nov 15 21:38:12 UTC 2013
Well using equals() would make byte code slightly larger and probably slow
down interpreter for no good reason, so it's not fully harmless (with JIT
code, yes, it's harmless).
Sent from my phone
On Nov 15, 2013 11:34 AM, "David Holmes" <david.holmes at oracle.com> wrote:
> On 15/11/2013 11:11 PM, Vitaly Davidovich wrote:
>> The amount of code in the wild that would break (if this were to change)
>> virtually guarantees that such a change won't happen, regardless of what
>> current spec does or does not say. It would probably be easier to just
>> update the spec at this point to match implementation.
> There is no need to update spec or implementation. Current code aligns
> exactly with spec and spec is perfectly valid. The change to use equals()
> over == was being proposed to future-proof the code in case the implicit
> specification of Class.equals were to change in the future. Harmless but
> pointless in my opinion.
>> Sent from my phone
>> On Nov 15, 2013 7:57 AM, "Stephen Colebourne" <scolebourne at joda.org>
>> On 15 November 2013 03:21, 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.
>>> I've used == for Class for many years. I expect many other developers
>>> have done the same. I think that changing Class so identity was not
>>> respected would break a *lot* of code.
More information about the core-libs-dev