Are there plans to have an option for jextract to create an optimized binding?

Christoph Läubrich laeubi at laeubi-soft.de
Fri Mar 10 10:23:19 UTC 2023


Hi Maurizio,

I have now played around with that option and the filtering works well!

I just found one possible way to built into jextract directly that could 
be quite simple:

While cleaning up the generated file I found my self very often simply 
stripping away anything "not from xyz.h", so I think an option like 
--limit header1.h,header2.h would reduce the manual work here!

of course one can write a shellscript for that as well, but as each line 
already has a comment

# header: /usr/include/myheader.h

it seems quite easy to implement that directly at jextract level!

Am 09.03.23 um 12:51 schrieb Maurizio Cimadamore:
> 
> On 09/03/2023 11:46, Christoph Läubrich wrote:
>> Hi Maurizio,,
>>
>> that already looks promising!
>>
>> Would be cool if jextract could even automate this, so it finds the 
>> symbols from existing class files?
>>
>> I can think about the following:
>>
>> 1) I generate all bindings
>> 2) I have my code and test finished, and run jextract again, passing 
>> it my jar file
>> 3) I get a binding with only things required.
>>
>> because for a complex binding I can think its quite hard to find out 
>> what I don't care about.
> 
> I think this is not impossible -  that said, I think the jextract tool 
> should provide primitive knobs, which are expressive enough to let 
> developers do what they want. For instance, the jar-analyzer tool you 
> describe could also be built on top of jextract.
> 
> Ideally, I think it would be nice if, one day, IDEs had some kind of 
> integration for this: the extraction process is interactive, and I think 
> that jextract would benefit greatly from some kind of UI. There's only 
> so much we can capture via simple command line options.
> 
> Maurizio
> 
> 
>>
>> Am 09.03.23 um 12:18 schrieb Maurizio Cimadamore:
>>> Hi Christoph,
>>> note that jextract already supports a filtering mechanism. The basic 
>>> usage is described here:
>>>
>>> https://urldefense.com/v3/__https://github.com/openjdk/jextract*filtering-symbols__;Iw!!ACWV5N9M2RV99hQ!NU_jGOsWk3eJe3kZW2eDc6W9aq6KhmLkOhY78Z7IH6iyWhIw6zT4bTtp_duQ_061rh7ybJcHWGE-vbehtkYce9DViH2B$
>>> That is:
>>>
>>> 1. you can run jextract in a way so that it dumps all the symbols it 
>>> could find during its execution (--dump-includes=<filename>)
>>> 2. you can then edit the generated file, and drop all the symbols 
>>> your application doesn't care about
>>> 3. you can pass the edited file back to jextract, as an "argfile" 
>>> e.g. "@<filename>"
>>>
>>> This will only generate bindings for the things you care about.
>>>
>>> Hope this helps
>>>
>>> Maurizio
>>>
>>>
>>> On 09/03/2023 11:05, Christoph Läubrich wrote:
>>>> Hi Panama Devs,
>>>>
>>>> I hope the mailinglist is the right place for such 
>>>> questions/discussions/ideas, as the github repository has not 
>>>> enabled Github-Discussions.
>>>>
>>>> jextract is doing a great work, but for some libs it produces a very 
>>>> very large result ( ~ 3000 files or more), I therefore wonder if it 
>>>> would be possible to have jextract passing some code (e.g. a jar) 
>>>> using the binding and then it generates an optimized binding that 
>>>> only contains the functions/constants that are actually used in the 
>>>> java code?
>>>>
>>>> thank in advance,
>>>> Christoph


More information about the panama-dev mailing list