Namespace for inner classes in jextract

[Duncan Gittins]

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> 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
>