Hi,
Though "compareTo" tends to be less efficient than "equals", it offers better
type safety.
When we (mistakenly!) compare objects of different type, "equals" silently
accepts parameter of wrong type,
but returns false. Comparison with "compareTo" is rejected by compiler.
Consider,
String string = ...
Date date = ...
if (string.equals(date)) { // always false
}
if (string.compareTo(date) == 0) { // compilation error
}
Regards,
Dmytro
> Date: Thu, 23 Feb 2012 10:58:47 -0500
> Subject: Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes
> major performance issues at scale
> From: vita...@gmail.com
> To: frederic.par...@oracle.com
> CC: serviceability-dev@openjdk.java.net; core-libs-...@openjdk.java.net
>
> Hi Frederic,
>
> Just curious - why are you checking string equality via compareTo() instead
> of equals()?
>
> Thanks
>
> Sent from my phone
> On Feb 23, 2012 10:37 AM, "Frederic Parain" <frederic.par...@oracle.com>
> wrote:
>
> > This a simple fix to solve CR 6988220:
> > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220>
> >
> > The use of String.intern() in the ObjectName class prevents
> > the class the scale well when more than 20K ObjectNames are
> > managed. The fix simply removes the use of String.intern(),
> > and uses regular String instead. The Object.equals() method
> > is modified too to make a regular String comparison. The
> > complexity of this method now depends on the length of
> > the ObjectName's canonical name, and is not impacted any
> > more by the number of ObjectName instances being handled.
> >
> > The Webrev:
> > http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/<http://cr.openjdk.java.net/~fparain/6988220/webrev.00/>
> >
> > I've tested this fix with the jdk_lang and jdk_management
> > test suites.
> >
> > Thanks,
> >
> > Fred
> >
> > --
> > Frederic Parain - Oracle
> > Grenoble Engineering Center - France
> > Phone: +33 4 76 18 81 17
> > Email: frederic.par...@oracle.com
> >
> >
