Bounds checks with unsafe array access
John Rose
john.r.rose at oracle.com
Wed Sep 10 19:58:51 UTC 2014
On Sep 10, 2014, at 6:04 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> It's not paranoid, most of the dependency injection libraries, Hibernate or serialization code allow you to set the value of final field at runtime.
For DI, maybe we should have a way for data structures to cooperate with this, by declaring lazy finals.
http://cr.openjdk.java.net/~jrose/draft/lazy-final.html
Serialization is sad, but I have hopes it can be partially rationalized, if we can figure out a better story for final variable life cycle.
A happier, more hopeful example is builders: A builder wants to create a blank "larval" instance with final fields, and then builder methods initialize the fields, and then the builder produces the "adult" instance which is immutable. This is easy to express with lazy finals. It could also be expressed if we were willing to delegate the peculiar privileges of constructors (relative to finals) to related bits of code, like friendly builder methods. There would have to be a flexible notion of larval vs. adult, which is partially implicit in the current rules about constructors.
The way we do it now is have the builder contain a copy of the build-ee's state, but mutable. There are two copying events that are annoying with this design pattern: 1. when I code the builder, I copy-and-paste from the build-ee and edit out all the "finals"; 2. when the builder creates the build-ee, it recopies stuff I just handed it via builder methods... I close my eyes and hope for sufficient copy-propagation from the JIT. The first annoying copy leads directly to the risk of the second.
— John
More information about the hotspot-compiler-dev
mailing list