Unreasonable size of jextract tool

[Filip Krakowski]

Hi,

I like the idea of a standalone jextract tool. Besides the resulting 
smaller size of the JDK, I also see more potential for contributions, as 
it will make the tool more visible and possibly easier to build/develop.

Currently the Gradle jextract plugin assumes that the tool is located 
within the JDK. However, changing this would be very easy and would not 
cause any problems. Since Gradle is not compatible with current nightly 
builds of the JDK and thus I can't access jextract during the build 
process via the API, I invoke jextract via a simple process call. In the 
future I plan to use the classes provided by jextract directly and 
remove the process call. Here (if jextract is distributed via Maven as 
JMH is) I would merely need to add a dependency, which is not a problem.

Best regards
Filip

On 5/24/21 6:49 PM, 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?