How to tell jextract to use different lib name for the same binding?

Christoph Läubrich laeubi at laeubi-soft.de
Wed Nov 13 11:02:23 UTC 2024


What I did in the past is to simply not specify the library to jextract 
at all.

The one of course need to load that in the application code, but at this 
place you can do whatever you want (including trying different names).

Maybe this works here as well?

Am 13.11.24 um 11:50 schrieb Maurizio Cimadamore:
> 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
>>


More information about the panama-dev mailing list