Apparently javac did at elide the "extraneous" null initialization at one point and it was deemed to have been contrary to point #4 of the procedure in JLS 12.5 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.5-220-D)
Mike On Apr 11 2014, at 12:57 , Martin Buchholz <[email protected]> wrote: > It's surprising that javac does not eliminate the redundant initializations > to null. Initializing to null has documentation value (suggesting that the > constructor will not assign a value; null is a "valid" value). How about > fixing javac instead? > > > On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou <[email protected]> wrote: > Hello all; > > This is a simple cleanup changeset that removes redundant initialization of > fields to null from a number of collection classes. These field > initializations may seem cheap but they do have a cost: > > - For volatile fields there is a measurable cost on some benchmarks for these > extra initializations. > > - Larger byte code in <init> methods. > > - For transient fields the initialization is misleading since it does not > occur on deserialization. > > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ > > Redundant null initializations in other components/packages will be handled > in separate issues. > > Mike >
