On Jul 31, 2020, at 12:41 PM, Brian Goetz <brian.go...@oracle.com> wrote: > > As far as I can tell what you're suggesting, it is that, when we detect a > field is not initialized, we initialize it for you with some sort of default. > But that brings us back to the main problem: what if the class _has no good > default_? With what do we initialize it?
I think he was going back to the old idea of an opt-in default value, which is then “stamped” all over arrays and fields. A very natural notation for this would be a no-arg constructor. In this world, the vdefault bytecode would be privileged (usable only inside the same capsule, to bootstrap value creation). Where we have public uses of vdefault today, we would instead have an API point, a call to the no-arg constructor factory method. The no-arg constructor would (presumably) be run just once, the first time needed, and the value stored somewhere. The JVM would want to special-case this somehow. Perhaps the API point would surface as a well-known public-static-final? The rest of the VM would do some tricks Dan is suggesting, to ensure that non-private uses of the type would always refer to the public default value. I think it would still be desirable for the class itself to work with “dangerous” all-zero instances (after all, it’s the class’s business to define exactly how dangerous they are), so that for example array creation inside the class might be faster than array creation outside the class. Personally, I view such tactics as possible but expensive, and would like to try to get by without JVM support for them, to start with. The JVM engineering teams are already overworked for Valhalla. — John
