Namespace for inner classes in jextract

[Maurizio Cimadamore]

Hi Duncan,
I did some preliminary work on this - available here if you want to give 
it a try:

https://github.com/openjdk/panama-foreign/compare/foreign-jextract...mcimadamore:non-nested?expand=1

I do believe that the above patch is prone to the clash issue you 
mentioned - but that only works "by accident" in the current codebase 
(e.g. the two definition happen to belong to different header containers).

So, it seems there's an issue with jextract not handling 
case-insensitive-ness on Windows/Mac, which we will need to rectify - we 
already have logic to avoid classes to be added with same name - seems 
like we need to make that check more robust (at least on some platforms).

Filed:

https://bugs.openjdk.java.net/browse/JDK-8263372

Maurizio

On 10/03/2021 12:26, Duncan Gittins wrote:
> Maurizio
>
> I would be very happy using either approach you mentioned if it 
> enables the ability to redo jextract without recompiling dependents, 
> avoids potential VM restrictions you highlighted and improve use of 
> these huge classes in IDEs. Eclipse is also unhappy with a big 
> Jextract, but am not sure if this is because of a single class limit 
> like IntelliJ or if just that the jar is vast.
>
> As an experiment I adapted my jextract to the first approach pulling 
> out every inner struct class to top-level [ ... 3 fun hours of regex 
> later ! ...] and discovered an issue (affecting both). Deep down in 
> the hierarchy of superclasses were these lines derived from winreg.h - 
> legal but bad practice:
>
>     typedef struct pvalueA {... } PVALUEA, FAR *PPVALUEA;
>     typedef struct pvalueW { ... }PVALUEW, FAR *PPVALUEW;
>     typedef PVALUEW PVALUE;
> Win_h_8.java:
>      public static class PVALUEA extends Win_h_5.pvalueA
>      public static class PVALUEW extends Win_h_5.pvalueW
>
> These definitions work in current jextract because PVALUEA and pvalueA 
> happen to be generated inside different classes (I did not check if 
> this is a feature or just accidental) but fail as top-level (or 
> "blessed" inner) classes as PVALUE/W.java overwrites pvalueA/W.java on 
> default Windows case-insensitive filesystems or give javac error for 
> inner class name-clash.
>
> I deleted these problem classes and tried out Eclipse - this IDE seems 
> happier with code-completion especially for constants inside the 
> slimmed down chain of the named header class. It would not bother me 
> if jextract just ignored definitions like PVALUEA/pvalueA - but it 
> might sway the decision making if you do want to support these 
> definitions too.
>
> Kind regards
>
> Duncan
>
>
>
>
>
>
>
>
> On Mon, 8 Mar 2021 at 16:20, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     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
>