Namespace for inner classes in jextract

[Maurizio Cimadamore]

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?