Namespace for inner classes in jextract

[Maurizio Cimadamore]

On 08/03/2021 12:34, Duncan Gittins wrote:
> Maurizio
>
> Yes -  as you say the the current generation works well for the 
> methods which are always resolved via the scope of Header_h.blah() 
> regardless of the superclass definitions, so the issues is just for 
> the nested classes (not constant$nnn.java)
>
> >> I see two ways out of here:
> >> * do what you propose (which then requires the extra import)
> >> * generate all nested classes inside the "blessed" header source 
> (the one with the stable name)
>
> The first option isn't that awkward as  "import mypackage.*" is all 
> that is needed and it can be easily tidied to the exact imports by any 
> decent IDE.
>
> Is there any VM limit on the number of nested classes allowed in the 
> top level "blessed" Header_h.java which means the second idea will not 
> scale well or is not feasible for huge jextracts?

There is a theoretical limit, in the sense that each inner class will 
add a constant to the constant pool, so, if we go real high we might run 
into issues. But this seems more of a limit on paper - as you'd need 
tens of thousands of structs/functional interfaces to hit the ceiling.

We could definitively run some experiments on the stuff we support now, 
and see how far are we from that limit (Window.h probably being the 
limit case).


>
> [Admittedly you may think this is something I should not be doing as 
> it could break in future!] For example I run 5x jextract with same -t 
> package so that just one copy of RuntimeHelper.class / VarargsInvoker 
> is shared with all the generated 5x Header_h definitions:
>
>     jextract -source -lole32    -t duncan.win -d java --filter 
> combaseapi.h --filter coml2api.h --filter guiddef.h --filter objidl.h 
> --filter objbase.h --filter unknwnbase.h -I %WINKIT% Ole32.h
>     jextract -source -lshell32  -t duncan.win -d java --filter 
> errhandlingapi.h --filter shellapi.h --filter shobjidl_core.h --filter 
> winuser.h                -I %WINKIT% Shell32.h
>
> ... plus each Header_h_nnn.LIBRARIES[] contains one library name and 
> not x5 when resolving symbols. [ Not to get any meagre performance 
> boost, just to look simpler. I could of course have used "-t 
> duncan.win.xyz" ]

I think this is not such a bad approach, and honestly I'd expect users 
to do something like that when working with huge monolithic headers 
which, in reality, are more a collection of separate libraries (not all 
of which might be used at the same time).

Maurizio


>
> Kind regards
>
> Duncan
>
> On 08/03/2021 11:15, Maurizio Cimadamore wrote:
>> I found myself asking the same question few weeks ago. It seems to me 
>> that there's value in having all functions belong to the same 
>> "header" class which you can import statically - because e.g. if you 
>> call a function:
>>
>> clang_version()
>>
>> is better (IMHO), than
>>
>> LibClang_h.clang_version()
>>
>> E.g. when calling functions, or accessing globals, the qualifier 
>> doesn't add much.
>>
>> The same is not true when interacting with structs, where a qualifier 
>> is gonna be needed anyway.
>>
>> So, this boils down, really, to how many imports we wanna ask the 
>> users to add to their programs; the motivation for the current 
>> structure is that we're like to ask a single static import - that 
>> would give you access to most of the stuff (functions, globals, 
>> structs and functional interface).
>>
>> If we go down the path you describe, I'd expect the majority of users 
>> to add a static import for the functions, and then another package 
>> star import for importing all the classes in the jextracted package.
>>
>> I don't have a strong preference here - but I'd like to point out 
>> that the current scheme is _very_ stable when it comes to referenced 
>> function symbols - here's a simple example:
>>
>> ```
>> class Sup {
>>    static void m() { }
>> }
>>
>> class Sub extends Sup { }
>>
>> class Main {
>>    void main() {
>>       Sub.m();
>>    }
>> }
>> ```
>>
>> If you look in the bytecode of `main`, you will see this:
>>
>> ```
>>          0: invokestatic  #2                  // Method Sub.m:()V
>> ```
>>
>> That is, no mention that the method actually comes from `Sup`. So the 
>> client here doesn't need recompilation if bindings are re-generated.
>>
>> But using nested names for structs and functional interfaces, yes, 
>> adds an extra dependency on the enclosing class.
>>
>> I see two ways out of here:
>>
>> * do what you propose (which then requires the extra import)
>> * generate all nested classes inside the "blessed" header source (the 
>> one with the stable name)
>>
>> While the second solution might seem odd, in reality it doesn't 
>> really change the footprint much (after all, nested classes still map 
>> in their own classfiles) - retains the advantages of current approach 
>> (only one static import from clients is required) and avoids the 
>> struct name instability you are referring to.
>>
>> Thoughts?
>>
>> Maurizio
>>
>> On 07/03/2021 14:10, Duncan Gittins wrote:
>>> Instead of emitting many inner classes which are defined somewhere 
>>> in the chain of the top level class+superclasses, have you 
>>> considered creating these as top level classes (perhaps in a 
>>> sub-package) so that their naming path would be consistent between 
>>> jextract re-runs - thus reducing the need to re-compile all 
>>> dependent applications? 
>
>