Unreasonable size of jextract tool
mbien42 at gmail.com
Tue May 25 07:48:06 UTC 2021
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)
On 24.05.21 18:49, Maurizio Cimadamore wrote:
> This is a very interesting question, and one that we often stopped to
> 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  but also
> distributed on Maven. Would a model like that be acceptable? One
> important use case is the gradle jextract plugin , 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.
>  - https://openjdk.java.net/projects/code-tools/
>  - 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
>> 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?
More information about the panama-dev