RFR: 7903597: Slim down RuntimeHelper

[Jorn Vernee]

On Fri, 1 Dec 2023 22:06:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Remove some of the helper methods in RuntimeHelper. They can be moved inline in the generated code.
>> 
>> Also: I've elected to move the `System.load(Library)` directives we generated inside RuntimeHelper into the first header class, in order to have it more localized to the actual code that a user sees. That also makes RuntimeHelper more 'dumb'. Only the package declaration is now injected into the template, which makes it easier for users to combined multiple extraction runs (they can just discard one of the generated RuntimeHelpers).
>
> src/main/resources/org/openjdk/jextract/impl/resources/RuntimeHelper.java.template line 27:
> 
>> 25:     static {
>> 26:         SymbolLookup loaderLookup = SymbolLookup.loaderLookup();
>> 27:         Linker linker = Linker.nativeLinker();
> 
> Question: with RuntimeHelper being so small now, and given one of the stated goal is to allow for better composition of different extractions, would it not be convenient to move all these definitions in the header class and ditch `RuntimeHelper` completely? If we do that, we might also avoid generating the varargs definitions unless we need them, so that the header class would only include minimal additional code.

I thought about this, and I think the main question is: in which header class do we generate the helpers if we have multiple classes? I wasn't sure if we'd be happy with duplicating the helpers in every header class (users might complain about the duplication). But, maybe the majority of cases will only ever see a single header class, so there's still a benefit.

I'll take another look at that. The conditional code generation is also an interesting benefit.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/150#discussion_r1412631649