Is a jextracted jar supposed to be published?

[Remi Forax]

----- Mail original -----
> De: "Sebastian Stenzel" <sebastian.stenzel at gmail.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Jeudi 28 Janvier 2021 14:06:47
> Objet: Is a jextracted jar supposed to be published?

>> On 28. Jan 2021, at 13:25, Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>> wrote:
>> 
>> Yes, the source generation is eager, while the class generation is as
>> lazy as possible, using every inch of VM features we have available
>> there. We could do more on the source side, to make things lazier
>> there, but we're at the fence - kind of hoping for this:
>> 
>> https://openjdk.java.net/jeps/8209964 <https://openjdk.java.net/jeps/8209964>
>> 
>> If we had this, then we could just use same strategy for both class AND
>> source and they would be both "naturally" lazy.
>> 
>> We do not have plans to remove the --source flag.
> 
> Above is a quote from the "Feedback / query on jextract for Windows 10" thread,
> which I didn't want to hijack. So I thought to create a new one instead. So far
> I have always been working with `--source`, however after reading the
> aforementioned, I'm reconsidering.
> 
> However, I really don't understand how jextracted .jar files are intended to be
> used. Without further artifacts such as a source jar, we can not just
> straightaway publish them to public repos like Maven Central, which effectively
> disqualifies them to be used as a dependency as is.

I have not all the answer :)

Technically the .h file is the source, a generated .java source file is not better than a .class file.
I can see IDEs in the fture being able to link the elements of a .h file with the corresponding class file representation. 

> 
> This brings me to the question: Is the jextracted jar file even intended to be
> "released" or should I consider it just an intermediate build artifact that
> _requires_ post-processing such as re-packaging (i.e. using
> maven-shade-plugin)?

Great question, it can also be like Ruby gems, the jar file is generated at the first installation.
I think it depends on from whom the .h file comes from and on which OS your program run,
on Windows the libraries tends to be backward compatible while on Linux, only the kernel OS calls are backward compatible so you may want to support several incompatible versions of the same library.

I hope jextract will have enough option to avoid shading because you loose the connection between the source code and class files with shading.
Shading is fine for an application, far less for a library.

> 
> I know that this question may be a bit off-topic, but since there seem to be
> significant differences between generated sources and classes, I thought I
> should bring up these "downstream problems" before it is too late.

Rémi