Constant descriptor resolved too soon during constant resolution?

[Brian Goetz]

On 8/26/2018 12:15 PM, Jorn Vernee wrote:
>>> ```
>>> public class EnclosingClass {
>>>
>>>     public static class MyClass {}
>>>
>>>     // 'const' because it's a reference to a constant pool entry
>>>     /* private */ const MyClass x = new MyClass(); // lazy-init
>>
>> Yes, now that we have condy, lazy statics have moved a bit closer.
>> But, the language side of the work is about 1% of the work.  The rest
>> is VM work to hook into field resolution so that we can trigger the
>> constant resolution on linkage.
>
> Well, my idea there was not to have any static field. `x` is just a 
> name used to refer to a backing constant.

Yes, that's the cheap way to get there.  (And sometimes cheap is good.)  
But what it means is that migrating a nonprivate field between non-lazy 
and lazy becomes a non-binary-compatible move.

> Automatically making statics lazy does sound much better though, since 
> you get the benefits just from re-compiling. 

Can't do this automatically, because it could perturb the order of 
class-initialization side-effects, and many programs depend (implicitly) 
on this.  But making a source change (non-lazy -> lazy) would be OK, 
since then the user is asking for new semantics (which presumably 
they'll test.)

> But I thought lazy statics were a no-go since the spec says that 
> static fields are initialized when the class is initialized, so making 
> them lazy would mess up the timing of side effects. Though I suppose 
> some static fields could be lazy and others not, depending on the kind 
> of side effects the initializer has. What's the idea there?
>

Right, so we can't do it automatically, but we can give the user the 
chance to opt into laziness.