Hi Alex,
String.equals already performs that instanceof comparison, and is one of the
first to be inlined by the hotspot. What I would do is to turn it...
this.equals(cs) instead of cs.equals(this).
Which would only improve performance if you have classes implementing
CharSequence other than
That's true, but given cs is a String with length equal to this,
cs.equals(this) nevertheless may return false, and
if (cs.equals(this))
return true;
will not return. The remaining code performs the comparison a second
time in this case.
Oh, now I see it - you are absolutely right
Osvaldo Doederlein wrote:
Em 22/11/2009 05:55, Thomas Hawtin escreveu:
There is a security issue there. When multiple threads are involved,
it is possible (though not necessily easy) to create a mutable String
if the backing char[] is shared.
Tom Hawtin
That's true. But there's
I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:
Paolo,
Look at this bug evaluation
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959 to get further
information about what Tom told you yesterday.
I'm afraid that there is nothing to do here... because an optimization based
on buffer-sharing + copy-on-write has several problems
Hi all.
I have measured the number of AbstractStringBuilder method invocations when
executing NetBeans 6 (and making some work for 5 minutes) and when executing
for a while a Glassfish V2 with a typical web application
(Struts+Spring+Hibernate). These are the interesting and empirical results:
