Constant descriptor resolved too soon during constant resolution?
Jorn Vernee
jbvernee at xs4all.nl
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