Namespace for inner classes in jextract

[Maurizio Cimadamore]

On 08/03/2021 14:25, Maurizio Cimadamore wrote:
> 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).

I did some experiments - and, using this approach on Windows.h, the 
first header uses 50% of the available number of constant pool entries.

In that case there are around 9K nested classes (!!), some of which are 
synthetic jextract classes (e.g. constant$xyz) but most of which are 
just real struct declaration and function pointer interfaces.

Surely having a single source with 9K nested classes is ugly, but having 
a single package with 9K classes inside doesn't seem to be much better?

Ultimately, Windows.h is just too big to work with it w/o filters - that 
said, the approach I proposed seem to work even in this extreme case.

There are another couple of factors to consider here (which hasn't been 
discussed previously); the first is that some IDE (e.g. IntelliJ) seem 
to have some default limit which excludes big enough source file from 
indexing. So, adding _more_ stuff to the main header is not great from 
that perspective.

Secondly, we need to consider impact in terms of javadoc - while right 
now we don't generate javadoc for extracted bindings, our plan is to 
start doing so; when we do, I believe there might be some difference in 
javadoc usability in the two approaches.

So, all things considered, even though it seems that the approach I 
proposed works well, even with monolithic headers, in reality I think 
that sooner or later we will be pulled (by some of the other concerns 
listed above) towards a direction where each generated file is smaller; 
so, unless we want to go back to an approach where things were grouped 
by header file (which we tried, and hated for many different reasons), 
the only credible alternative I see here is the one Duncan proposed - 
that is, give up on the dream of including everything with a single 
import, and generate helper classes like structs and functional 
interface separately.

My 0.02$.

Maurizio