jextract JDK19 Windows enum handling
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Jun 8 11:13:46 UTC 2022
After thinking some more, I don't think there's a sane way to keep both
--include-enums and having a more fine-grained enum constant option. The
mechanism we have now is very simple, where jextract just dumps whatever
it finds on a set of disjoint include-xyz flags. We could in principle
tweak the impl so that --include-enum included "all constants" whereas
if that flag is missing, it falls back to use --include-constant - but
then what would jextract dump?
Since the boundary between enums and defined constants is so blurry in
C, I'm inclined to just revert.
Maurizio
On 06/06/2022 10:37, Duncan Gittins wrote:
> I hope it would be possible to deal with both ways for (2). The
> --include-enum option works very well when there are a few values per
> enum like SLGP_FLAGS (even though I only need SLGP_SHORTPATH), but
> there are some enums which contain many more definitions and the view
> of the generated code and IDE code completion) looks very bloated when
> it contains so many unreferenced definitions.
>
> Due to the bug (1) my compiled jextract jar is 45% bigger than under
> JDK18 jextract - that is quite a jump if my Java code was only
> dependent on one item from each of those enums that are incorrectly added.
>
> Kind regards
>
> Duncan
>
> On Sun, 5 Jun 2022 at 22:35, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>
> Hi Dunan,
> (1) looks like a bug. I'll need to think about (2). I see where
> you are
> coming from. At the same time it's tricky, because we filter out most
> stuff by "name" (e.g. struct name, function name, etc.) - and we
> do not
> provide functionality to filter out at _deeper_ levels of nesting.
> The
> fact that constants worked the way they did was more of an happy
> accident rather than the result of a conscious decision.
>
> While we could go back to previous behavior, I feel like, in some
> cases
> at least, a developer might want to include an entire enum, w/o
> really
> having to enumerate all the constants.
>
> Maurizio
>
> On 05/06/2022 13:47, Duncan Gittins wrote:
> > I'm a bit behind with all latest Panama messages so apologies if
> this
> > repeats existing issues. I've been testing out latest jextract
> from master
> > branch, along with jdk19 - both with non-incubator foreign
> package names.
> >
> > There are some unexpected enum values in extractions, perhaps
> related to
> > https://bugs.openjdk.java.net/browse/CODETOOLS-7903198
> >
> > Test with header file "Shell32.h" which contains "#include
> <shlobj_core.h>"
> >
> > 1) With latest JDK19 branch I see an enum that I don't use, and this
> > appears every time regardless of "--include--xxx" flags:
> >
> > jextract --source -lshell32 -t win.shell --output
> shell19.src Shell32.h
> > --include-enum THIS_DOES_NOT_EXIST
> > => Shell32_h contains 100+ values of "WELL_KNOWN_SID_TYPE"
> >
> > [ BTW: It would be nice if jextract had a mode (eg
> "--show-warnings") which
> > reported "No such enum: THIS_DOES_NOT_EXIST".]
> >
> > 2) Is there a way to extract one enum value SLGP_SHORTPATH with
> JDK19
> > jextract?
> >
> > In previous JDK18 jextract release I could extract a single enum
> value
> > SLGP_SHORTPATH (with "--include-macro" which was changed in
> > CODETOOLS-7903198)
> >
> > jextract --source -lshell32 -t win.shell --output shell18.src
> > Shell32.h --include-macro SLGP_SHORTPATH
> > => class Shell32_h { // omitted lines with Constants$root....
> > public static int SLGP_SHORTPATH() { return (int)1L; }
> > }
> >
> > Adding "--include-enum SLGP_FLAGS" will introduce new
> definitions including
> > SLGP_SHORTPATH (and WELL_KNOWN_SID_TYPE), but it would be nicer
> to have
> > just a single definition for the value "SLGP_SHORTPATH".
> >
> > Kind regards
> >
> > Duncan
>
More information about the panama-dev
mailing list