Namespace for inner classes in jextract

[Duncan Gittins]

On 10/03/2021 12:26, Duncan Gittins wrote:
> 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.

If/when jextract supports --symbols includefile to filter by name then 
it could also incorporate syntax to specify aliases to resolve a name 
clash, eg "pvalueA=MYpvalueA"

Duncan

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
>