No particular reason. But after thinking more about it, equals() should be a better choice, clearer code, and the length check in equals() implementation is likely to help performance of ObjectName's comparisons as ObjectNames are often long with a common section at the beginning.
I've updated the webrev: http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ Thanks, Fred On 2/23/12 4:58 PM, Vitaly Davidovich wrote:
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" <[email protected] <mailto:[email protected]>> 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 <tel:%2B33%204%2076%2018%2081%2017> Email: [email protected] <mailto:[email protected]>
-- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: [email protected]
