Constant descriptor resolved too soon during constant resolution?

[Brian Goetz]

> And when thinking about the possible future of dynamic constants had 
> come up with the following straw man for language support for the 
> above pattern:
>
> ```
> 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.

Stateless lambdas can also be translated with condy.

> The story with most of the ideas for folding I've had is that they all 
> inadvertently discard or change the timing of side-effects. So I was 
> holding off on bringing up more ideas until you had found a way of 
> dealing with that. The only thing I can think of myself is either some 
> thorough static analysis to check what side-effects a method has, to 
> see if it's observably side-effect-less, or just trying to invoke a 
> method if the arguments are constant, and then bailing out if a 
> side-effect is encountered. Both of those would require time, and 
> could possibly have problems with finding all the (non-jdk) classes 
> they need, so doing something like that at jlink time seems like a 
> natural fit, since at that point you should have access to all/most of 
> the classes of the application.

Yes, we're discussing that now.  The side-effects story is a deep rabbit 
hole; not only do you have the obvious side effects (those that are 
manifest in the method to compute the constant), but there's also class 
loading, class initialization, method linkage, etc.  We're trying to 
come up with a more principled story of which are safe to elide and 
which not.