Unreasonable size of jextract tool

[Michael Bien]

Hello,

as you mentioned its likely that jextract is going to be mostly used via 
maven plugins (or equivalent) since it will end up being a step in the 
build at the end of the day. So from a users POV it won't make a big 
difference (the plugin would just download it as dependency in the 
background or expect it to be there or fail) - both options are similar 
- devs are used to both.

However having it decoupled from the JDK might have its benefits, for 
instance the option to use newer jextract while sticking to a future LTS 
release of the JDK. Or maybe the API (jdk.incubator.jextract) could be 
allowed to be less stable in the beginning without having to worry about 
--enable-preview flags since devs can update the dependency at their own 
pace independent of the JDK.

The disadvantage is that the out-of-the-box experience of the JDK would 
suffer a little, since a cool tool is missing (I don't mind the few MB 
more, it won't end up in a container anyway).

I would be fine with any of the two scenarios. We waited for something 
like panama for a long time, we don't worry that much about how its 
packaged at this point ;)

(got encouraged to post this here from twitter)

best regards,
michael

On 24.05.21 18:49, Maurizio Cimadamore wrote:
> Hi,
> This is a very interesting question, and one that we often stopped to 
> ponder.
>
> What you say is true - the static footprint of libclang is pretty 
> high, and we have made several experiments to try and reduce that, but 
> w/o much success (as the small libclang.so needs to depend on the 
> bigger LLVM backend). Static footprint is not the only think we're 
> concerned about: I think that the jextract tool isn't necessarily 
> subject to the same degree of compatibility requirements which apply 
> to the various tools shipped with the JDK. For instance, it would be 
> ok (and I say, even desirable) to have the shape of the generated 
> bindings change frequently, as new Java features become available. For 
> instance, if Valhalla becomes available we'd probably want to use it 
> to model carrier types in the generated bindings. Or, if some form of 
> "lazy statics" becomes available, we might be able to reduce the 
> footprint of the generated code (by dropping the various Constant$XYZ 
> classes that are co-generated).
>
> What you suggest (standalone) tool is very much on the table - in fact 
> you will notice that we have been trying pretty hard to avoid any 
> dependencies on the JDK internals from jextract. That is, the 
> jdk.incubator.jextract package is completely standalone.
>
> For the purpose of the EA binaries, I think having jextract in the 
> same place makes sense, so that people can get a feel of the API and 
> the toolchain. But, strictly speaking, there's nothing keeping 
> jextract _inside_ the JDK.
>
> I'd be curious to hear feedback from folks who have been using 
> jextract - would it make a significant difference to you if jextract 
> was delivered in some other way? The closest thing I can think of is 
> JMH, which is available in the code tools repository [1] but also 
> distributed on Maven. Would a model like that be acceptable? One 
> important use case is the gradle jextract plugin [2], so I'd be 
> curious to understand if there would be significant repercussion on 
> tooling build on top of jextract, were jextract to be delivered 
> outside the JDK.
>
> Thanks
> Maurizio
>
> [1] - https://openjdk.java.net/projects/code-tools/
> [2] - https://plugins.gradle.org/plugin/io.github.krakowski.jextract
>
> On 24/05/2021 17:26, Glavo wrote:
>> I noticed that the jextract tool uses libclang to parse C code. On 
>> windows,
>> the libclang.dll size is 67.8m, even the compressed size is about 
>> 25m. This
>> makes the size of openjdk compressed package expand by 27.78%, the
>> decompressed volume of openjdk expand by 34%.
>> For a tool that is not commonly used, I think this is very unreasonable.
>> Should we consider reducing its size in some way or distributing it as a
>> stand-alone tool rather than as part of the JDK?