Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8084563 | emb-9 | Aleksey Shipilev | P4 | Resolved | Fixed | team |
While this make seem a smart move, it actually confuses people into believing this is an approved
practice of null checking.
With JDK 7, we have Objects.requireNonNull that provide the proper null checking, and declare the
intent properly. There is no performance implications of using it instead of getClass():
http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
(Actually, there *are* a few stubborn corner cases with performance implications; see JDK-8042127.)
- backported by
-
JDK-8084563 Replace obj.getClass hacks with Objects.requireNonNull
-
- Resolved
-
- duplicates
-
JDK-8025100 Use j.u.Object.requireNonNull in j.l.invoke codebase
-
- Closed
-
- relates to
-
JDK-8130758 Replace obj.getClass with Objects.requireNonNull
-
- Resolved
-
-
JDK-8042127 Performance issues with java.util.Objects.requireNonNull
-
- Open
-
-
JDK-8073550 java* tools: replace obj.getClass hacks with Assert.checkNonNull or Objects.requireNonNull
-
- Closed
-
-
JDK-8073432 Object.getClass() throws stackless NPE, due to C2 intrinsic
-
- Resolved
-
-
JDK-7041258 Use j.u.Object.requireNonNull in the JDK codebase
-
- Closed
-