JDK-8167005 : Comment on the need for an empty constructor in ArrayList$Itr
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-10-01
  • Updated: 2021-03-03
  • Resolved: 2016-10-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b140Fixed
Related Reports
Relates :  
JDK-8166840 - Synthetic bridge constructor in ArrayList$Itr blocks inlining
Description
As suggested by Stuart Marks in the review thread for JDK-8166840, we should add a comment as to why an empty constructor is important in the private inner Itr class, to avoid it being accidentally "cleaned up"
Comments
Shorter alternative: // prevent creating a synthetic constructor Itr() {}
04-10-2016
The original rationale for adding a package-access constructor was to work around the inability of Hotspot to optimize away this case. However, it makes sense to leave the constructor in place even after Hotspot is fixed. Having the class itself be private makes sense, as it's a strong statement of how the class is used. Without an explicit constructor declaration, a private no-arg constructor is generated. Unfortunately, in order for the outer class to call this constructor securely, javac generates a synthetic "nonce" class. This implementation technique is unlikely to change for the forseeable future. Adding a package-access constructor prevents generation of this extra class. This is an odd case where adding some source code actually reduces the size and increases the performance of the resulting output. We're willing to put up with some extra complexity in the libraries to benefit the system as a whole, so this code should stay in with an explanatory comment. I'd suggest something like this: // prevent generation of synthetic class required for access to private constructor Itr() { }
03-10-2016