no good default issue

[John Rose]

On Jul 31, 2020, at 12:41 PM, Brian Goetz <brian.goetz at 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