Jextract generates all bindings in the same class; that means that structs and functional interfaces are nested inside the main header file. This is convenient, as this allows a client to import everything in a single shot (with a single toplevel static import).

But it has drawbacks as well:

* Some of the binary names generated for the bindings are not stable, and can change depending on filtering - this is because, when header splitting kicks in, a struct class can end up in any of the splitted headers, depending on how much stuff has been extracted before that point

* IDEs have an hard limit when it comes to file indexing; nesting everything in the same source file can, in extreme cases, generate a sourcefile so big that the IDE gives up on indexing

* generated classfiles contain a lot of boilerplate associated with InnerClass and nestmate attributes; while the overhead associated with those attributes is small (most of it affecting classfile parsing), it can add up, and it contributes to increasing the compiled size of the generated bindings.

* javadoc - in a world where each generated binding gets its own javadoc comment, having nested entities can make browsing the javadoc harder (as all the entities are presented as "nested" in the javadoc output).

For these reasons, it might be worthwhile to consider as to whether jextract should just emit toplevel classes instead of nested ones. This doesn't change the usability of the generated bindings much - but it does require at least an extra import statement, to import all classes in the extracted package.