JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

Remi Forax forax at univ-mlv.fr
Sun Mar 10 11:21:47 UTC 2019


----- Mail original -----
> De: "Martin Buchholz" <martinrb at google.com>
> À: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 8 Mars 2019 21:35:59
> Objet: Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

> On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev <amaembo at gmail.com> wrote:
> 
>> Hello!
>>
>> > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
>> > --- a/src/java.base/share/classes/java/lang/Throwable.java    Thu Mar 07
>> > 10:22:19 2019 +0100
>> > +++ b/src/java.base/share/classes/java/lang/Throwable.java    Fri Mar 08
>> > 02:06:42 2019 -0800
>> > @@ -874,8 +874,7 @@
>> >           // Validate argument
>> >           StackTraceElement[] defensiveCopy = stackTrace.clone();
>> >           for (int i = 0; i < defensiveCopy.length; i++) {
>> > -            if (defensiveCopy[i] == null)
>> > -                throw new NullPointerException("stackTrace[" + i + "]");
>> > +            Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i
>> > + "]");
>>
>> Won't it produce unnecessary garbage due to string concatenation on
>> the common case when all frames are non-null?
>>
> 
> I share Tagir's doubts.  I avoid this construction in performance sensitive
> code.
> Java doesn't offer syntactic abstraction (can I haz macros?) so the Java
> Way is to write the explicit if.
> 
> Logging frameworks have the same trouble.
> https://github.com/google/flogger


No, they don't if the API use the pattern described by Peter
https://github.com/forax/beautiful_logger

> 
> Perhaps hotspot's improved automatic NPE reporting makes the message detail
> here obsolete?

anyway, i agree with what's Martin and Tagir said, requireNonNull() should not be used in this particular case.

Rémi


More information about the core-libs-dev mailing list