Constant descriptor resolved too soon during constant resolution?

Jorn Vernee jbvernee at
Sun Aug 26 16:15:06 UTC 2018

>> ```
>> 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.

Automatically making statics lazy does sound much better though, since 
you get the benefits just from re-compiling. 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?

More information about the amber-dev mailing list