String.substring when beginIndex is the string's length
Claes Redestad
claes.redestad at oracle.com
Thu Feb 19 00:51:12 UTC 2015
Hi Zoltan,
1. Well, obviously, there's an empty string at the end of all Strings which
you can index into! ;-)
(I guess it was a coin toss originally. Since it'd be a bit
inconsistent if say "foo".substring(0, 0) returned "" while, say,
"".substring(0, 0) threw a tantrum, I'd like to think the current impl was
favored for good reason)
2. https://bugs.openjdk.java.net/browse/JDK-8067471 was recently discussed
and a patch which actually optimizes away the array creation was pushed
into JDK9:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c60cf8acabb2
Going further and removing the String allocation entirely (returning "")
might have unexpected side-effects for some code expecting a new, distinct
object. Any potential benefit might also be eaten up by increased byte
code,
more branches etc.
HTH!
/Claes
On 2015-02-19 01:16, Zoltan Sziladi wrote:
> Hi,
>
> There are 2 things I do not understand about how substring works, hopefully
> someone can shed some light on it.
>
> 1. When you call substring and you provide the string's length as
> beginIndex, why does it return an empty string instead of throwing an
> exception? You are effectively indexing outside of the string: you index a
> character that is after the last character. Obviously this won't be changed
> since probably lots of code depend on this already, but still, I just don't
> get the logic behind it.
>
> 2. In this specific case (when beginIndex is the string's length) there
> seem to be a lot of unnecessary method calls for returning an empty string:
> String constructor -> Arrays.copyOfRange -> System.arraycopy
> All of these calls do some checks and in this case pass around 0's a lot,
> even creating array of 0 length, etc.
> My question is, would it make sense to include an if so that if subLen ==
> 0, then it would return an empty string? Or it has too much overhead if we
> consider how often this case occurs and it would be better to lose on
> performance on these rare occasions while keeping the general case 1 if
> faster?
>
> Thanks in advance!
>
> Regards,
> Zoltan
More information about the core-libs-dev
mailing list