On 15/11/2013 11:11 PM, Vitaly Davidovich wrote:
+1
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.
David
-----
Vitaly
Sent from my phone
On Nov 15, 2013 7:57 AM, "Stephen Colebourne" <scolebou...@joda.org> wrote:
On 15 November 2013 03:21, Joseph Darcy <joe.da...@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.
Stephen
