[foreign] RFC: Lazy symbol resolution

[Maurizio Cimadamore]

Hi Jorn,
this is an option I also considered in the past, e.g. using an indy to 
implement the method. At the time I decided against it, because I think 
that, in this phase, it would be preferrable to have eager failures in 
case something went wrong either at extraction time or at binding time. 
And I think that would still be the case.

If you don't mind, let's keep this in our backpocket - it is clearly 
where we need to be longer term, but I'm not sure that now is the right 
time to be adding this functionality, as it can hide test failures (even 
though I notice that the flag is disabled by default).

Maurizio

On 17/01/2019 13:04, Jorn Vernee wrote:
> Hi,
>
> Currently HeaderImplGenerator eagerly resolves symbols from the native 
> header interface while generating the backing implementation. 
> Sometimes the symbols defined in a single header are compiled into 
> multiple shared libraries. All of those libraries have to be included 
> when jextracting the header with `-l`, and all of them have to be 
> loaded when generating the header interface implementation. Because 
> symbols are eagerly resolved, every symbol in a header has to be 
> loaded at the time of header generation.
>
> I've thrown together a patch which trades in the eager resolution for 
> lazy resolution using dynamic constants that were recently added to 
> the jdk. Using the flag java.foreign.binder.LAZY_RESOLUTION=true the 
> bahaviour can be turned on. The main advantage is that not every 
> symbol in a header interface has to be present at runtime, while 
> symbols that _are_ present can still be used.
>
> Webrev: 
> http://cr.openjdk.java.net/~jvernee/panama/webrevs/lazyresolution/webrev.00/
>
> What do you think of this idea? Is lazy resolution desirable?
>
> Jorn