Hi all,
On 2013-11-16, Remi Forax wrote:
On 11/15/2013 04:21 AM, Joseph Darcy wrote:
Hello,
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
On 11/15/2013 04:21 AM, Joseph Darcy wrote:
Hello,
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
On 11/15/2013 10:04 PM, John Rose wrote:
On Nov 14, 2013, at 7:21 PM, 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
On Thu, Nov 14, 2013 at 07:21:38PM -0800, Joseph Darcy wrote:
Hello,
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
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
+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.
Vitaly
Sent from my
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
On Nov 14, 2013, at 7:21 PM, 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
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.hol...@oracle.com wrote:
On 15/11/2013 11:11 PM, Vitaly
Hello,
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
Hi,
Please review the fix for JDK-8027470 below.
Description:
AnnotationSupport compared Class-instances using '==' where it should be using
'.equals'. Fixed in this patch.
Link to web review:
http://cr.openjdk.java.net/~alundblad/8027470
Link to bug reports:
Hi Andreas,
On 31/10/2013 7:49 PM, Andreas Lundblad wrote:
Hi,
Please review the fix for JDK-8027470 below.
Description:
AnnotationSupport compared Class-instances using '==' where it should be using
'.equals'. Fixed in this patch.
Class is final and does not override Object.equals
12 matches
Mail list logo
