I and others have tried to track down the compiler issue in which this change was made. If anyone can point us in the right direction it would be nice to reference that issue.
Mike On Apr 11 2014, at 13:09 , Chris Hegarty <chris.hega...@oracle.com> wrote: > >> On 11 Apr 2014, at 21:04, Mike Duigou <mike.dui...@oracle.com> wrote: >> >> 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) > > I remember talking to Maurizio about this a few years ago. I think he > mentioned something similar. > > -Chris. > >> >> Mike >> >> >>> On Apr 11 2014, at 12:57 , Martin Buchholz <marti...@google.com> 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 <mike.dui...@oracle.com> >>> 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 >>
