November 2024 - jextract-dev

Flathub is not accepting my app that uses Foreign Functions and Memory API
by Davide Perini 25 Nov '24

25 Nov '24

Hi there, I wrote a small app that uses Foreign Functions and Memory API to show some toasts on Linux using libnotify. The bindings is available here: https://github.com/sblantipodi/firefly_luciferin/tree/dx12_pipeline/src/mai… Flathub maintainers are not accepting my app because they say that libnotify is already included in their runtime and that the libnotify is "build only". I bundled the builded .so file in my app and it works well, but they don't like that I need a .so file for this and they are not accepting my app. Is there something I'm not understanding? https://github.com/flathub/flathub/pull/5874#discussion_r1854943995 Is there a way to do what I'm doing better? Thanks Davide

2 2

warning: 'dllexport' attribute only applies to ...
by Jonathan Rosenne 18 Nov '24

18 Nov '24

With the new version 22-jextract+6-47 I am receiving the following warning: "warning: 'dllexport' attribute only applies to functions, variables, classes, and Objective-C interfaces" The functions are defined indirectly (by means of a macro) for as __declspec(dllexport) The output is identical to that produced by the previous version. Best Regards, Jonathan Rosenne

2 1

Re: How to tell jextract to use different lib name for the same binding?
by Maurizio Cimadamore 13 Nov '24

13 Nov '24

Hi, thanks for the feedback, and the positive comments :-) I see what you mean - you basically have two possible names for the library, and either one or the other should "match". Now, the jextract code could be updated a little. For instance, jextract could be a bit smarter when creating the library lookup: if an exception is thrown, some kind of "empty lookup" could be used. This would avoid exceptions being thrown. This is doable -- but the question then becomes: what if a user really expects a library to be there? In that case, the exception would be "swallowed" only to pop up later, e.g. when the first downcall is created (at which point the bindings will fail because no symbol for the downcall could be found -- given the library has not been loaded at all). So, doing a change like the one you suggest amounts at attempting to read the user mind (and all tools -- jextract included -- are notoriously bad at that :-) ). Now, it might be that the "exception swallowing" behavior I described above is more generally useful than what we do now, but with things like these I'm always afraid that what's best for some developers might not be best for others. So... we need more feedback from all of you to understand whether such a change would be perceived as beneficial. A similar issue was also discussed here: https://mail.openjdk.org/pipermail/jextract-dev/2024-September/001949.html Note also that, longer term (as mentioned in that discussion) we have plans to allow custom SymbolLookups to be plugged in by users, so that jextract can get away with "less mind reading". Cheers Maurizio On 13/11/2024 10:35, Davide Perini wrote: > > Hi all, > I'm starting to use jextract to workaround some issues I found in AWT. > AWT uses 20+ years old APIs for notifications and tray icons and it > doesn't work well in recent Linux distros and on Windows 11 24H2. > > I must say that foreign memory API is a massive improvement to the > Java ecosystem, wow. > I created a binding for the tray icon and for the notification API in > minutes, this is awesome. > > To create my bindings I start with jextract with something like this: > jextract \ > -l ayatana-appindicator3 \ > -l appindicator3 \ > .... > /usr/include/libayatana-appindicator3-0.1/libayatana-appindicator/app-indicator.h > > > With this command I would tell to jextract to search for > ayatana-appindicator3 > or > appindicator3 > > but when I use the binding it throws an exception if one of the two > libs are not present. > > > Libs uses the same interfaces and I don't need two bindings for these > two libraries. > > Is it possible to tell to jextract to create a binding that searches > for "multiple lib name" and don't throw and error in the event that > one lib is found? > > Thanks > Davide >

2 1

New jextract build released (22-jextract+6-47)
by Jorn Vernee 08 Nov '24

08 Nov '24

Hey all, We just published a new jextract build. We've added a new build for the Linux/AArch64 platform. Besides that, these are the other user-facing changes that are worth highlighting: 7903782: clang warnings and diagnostics below warning level should be logged as well [1] 7903779: unify logger messages to show position whenever possible [2] 7903776: jextract generates uncompilable code when C identifier with the name from "java.lang" classes is used [3] 7903777: jextract layout for enum with big constant values is wrong [4] 7903755: multi header support and special syntax for header file [5] I want to call special attention to the last entry in this list: It is no longer required to specify the full path of the header file you want to extract. The header file just has to be findable in one of the locations specified through the -I options. This should simplify the command line somewhat. It is also possible to use the form <foo.h> to pass a file to jextract (given sufficient shell quoting [6]). Doing this mimics the behavior of a header file included like #include <foo.h> within a C source file, which looks in a standard list of system directories for the included header file. Though the exact directories that are searched is platform dependent, it's possible to show the header file search directories by using a compile_flags.txt [7] file with the --verbose option. For example, by default, on my Windows machine, this prints something like: #include "..." search starts here: #include <...> search starts here: C:\<path to>\jextract\runtime\conf\jextract C:\<path to>\<current directory> C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\winrt End of search list. This latest version of jextract still targets Java 22 as a baseline, but the generated bindings will work on Java 23 as well. If you find any issues with the new build, please report them back to this mailing list (jextract-dev(a)openjdk.org) Thanks, Jorn [1]: https://bugs.openjdk.org/browse/CODETOOLS-7903782 [2]: https://bugs.openjdk.org/browse/CODETOOLS-7903779 [3]: https://bugs.openjdk.org/browse/CODETOOLS-7903776 [4]: https://bugs.openjdk.org/browse/CODETOOLS-7903777 [5]: https://bugs.openjdk.org/browse/CODETOOLS-7903755 [6]: '<foo.h>' in most shells, ^^<foo.h^^> in cmd.exe [7]: https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#additional-cla…

2 2