Constant descriptor resolved too soon during constant resolution?

Brian Goetz brian.goetz at
Sun Aug 26 18:39:26 UTC 2018

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.

More information about the amber-dev mailing list