[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