[NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened
Ulf Zibis
Ulf.Zibis at CoSoCo.de
Thu Mar 2 13:32:17 UTC 2017
HI,
first sorry for missing the class wide definition.
Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich:
>
> On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis <Ulf.Zibis at cosoco.de <mailto:Ulf.Zibis at cosoco.de>> wrote:
>
> In any case, what's the reasonable of checking an argument, which is not used in that case?
>
> My understanding is contracts like the above (let's assume it still called out the NPE in 8) are
> checked even if the argument isn't used in some cases. The other case where I believe this is
> done is when passing a Supplier to some method that uses it to obtain a default value - even if
> it's not needed, it's checked for null because most (all?) such methods stipulate that it cannot
> be null.
On the other hand, the null check is a waste of performance and footprint (implicits performance
cost too).
I can't imagine, if any programmer would rely on such contract, instead of doing the check
explicitly if of significance.
I think, the original reasonable of the contract is to rule out any other exception type or
undefined behaviour in case of relevance of the argument. So I would vote for stating the contract
more precisely in that way.
Also, if I remember correct, if a variable, here replStr, is only referenced later, the compiler can
move the execution of here replacement.toString() to a later position, so it is not clear to me, if
the original implementation ever fulfilled the contract.
-Ulf
More information about the core-libs-dev
mailing list