Feedback / query on jextract for Windows 10

[Maurizio Cimadamore]

On Mon, 2021-02-01 at 09:31 +0100, Remi Forax wrote:
> Another intermediary solution is to implement the lazy keyword in the
> compiler (javac) but only enable it under a flag. So that flag can be
> used when compiling java.base and jextract generated classes.

I'd avoid such hacky solutions :-) 
In my experience, people look at those "hidden" flag, and then before
you know it, you start seeing code in the wild that depends on them
(few years ago I saw code still using -jsr14).

> 
> 
> 
> For me the non-static lazy is a non problem, Java already considers
> separately final field and static final field, so lazy can be only
> allowed on static final fields, but neither on static fields nor on
> non-static fields. 

I tend to agree - allowing dynamic constants in the constant value
attribute seems to be a straightforward generalization of what we have
now.

Exploring the space of non-static lazy final is a possibility, but I
don't think that exploration should block what would seem like a
generally useful strategy (being forced to use classfile generation
just because there's no language support for lazy static constants
seems like a suboptimal situation).

My intuition also tells me that non-static constant will likely not be
as interesting; at least in the method handle/var handle case you want
these things to be static - so that C2 can see their constant-ness -
so, if a "Constable" instance is likely what we'd like to use the lazy
support for, then I'd say that tying that to "static" seems a
relatively forced move (at least given the VM we have today).

Maurizio