> That doesn't remove the performance difference when the string is NOT upper
> case.
When the code is C2 compiler there is no significant difference, but in
interpreter mode it's noticeable.
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
public class StringEquali
On Tue, Oct 29, 2019 at 1:12 PM Rob Spoor wrote:
>
> I agree. There is no reason to use == instead of equals. Not for
> readability, because it will most likely confuse people who will come
> asking why you're not using equals. Not for performance, because since
> at least Java 7 String.equals sta
On 28/10/2019 21:34, Florian Weimer wrote:
* Сергей Цыпанов:
Hello,
current implementation of e.g. String.toUpperCase() returns the object
it was called on in case all code points are in upper case.
E.g. this test
@Test
public void upperCase() {
String str = "AZ";// Englis
* Сергей Цыпанов:
> Hello,
>
> current implementation of e.g. String.toUpperCase() returns the object
> it was called on in case all code points are in upper case.
>
> E.g. this test
>
> @Test
> public void upperCase() {
> String str = "AZ";// English
> assert str == str.toUpp
Hello,
current implementation of e.g. String.toUpperCase() returns the object it was
called on in case all code points are in upper case.
E.g. this test
@Test
public void upperCase() {
String str = "AZ";// English
assert str == str.toUpperCase();
str = "АЯ";
