Namespace for inner classes in jextract

[Duncan Gittins]

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?

Although I like simplicity of first, the second way is more flexible as 
it avoids name clashes of the new top level classes versus the 
auto-generated "RuntimeHelper", plus it conveniently supports multiple 
header jextracts to one directory.

[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" ]

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?