Feature: Add support for jextract

[overheadhunter]

• I have read the CONTRIBUTING guidelines
• I've had a conversation on the #cli-development Slack channel about this request.

Feature request

The jextract tool used to be part of the JDK in older builds of Project Panama but has been externalized to decouple the release cycle. It helps generating Java bindings from C header files using the FFM API (currently still in preview).

You might want to have multiple versions of jextract installed at the same time, each of which compatible with a different JDK. SDKMAN! would simplify managing those installations.

[helpermethod]

Hi @overheadhunter,

just gave it a quick look, and it's possible to distribute jextract via SDKMAN!.

But note that only ea builds currently exist, so at some point the URLs pointing to the binaries may stop working.

@marc0der Wdyt? I guess it would be a great addition to SDKMAN!.

[marc0der]

Yep, I see no problem in supporting jextract, although we would need to do some additional work as it is only distributed as .tgz.

[helpermethod]

@marc0der Prebuilt binaries are distributed as .tar.gz. Do we need to make changes to the sdkman-candidates service?

[marc0der]

We will need to make some changes to hooks to handle this. After that we can merge. I'll see what I can do over the weekend.

[marc0der]

Okay, I've deployed the changes to sdkman-hooks. I'll unblock the PR @helpermethod

[marc0der]

Hi @overheadhunter, we released Jextract but realised it includes java and javac too. This is a big problem because it clobbers the java binaries provided by our java candidate. I will need to pull Jextract for now until this issue is resolved.

[helpermethod]

I've asked on the jextract-dev mailing list if they could remove java and javac from the binaries but it doesn't seem that easy

Hi,
While removing javac should be doable, I think dropping the java
launcher is more problematic, as that launcher is called by the jextract
launcher.

So, doing something like that would require a deeper restructuring of
the build layout I'm afraid.

Maurizio

So I fear we can't support jextract any time soon.

[overheadhunter]

I have seen Maurizio's answer as well.

I guess adding a different dir to PATH, which solely contains a symlink to the jextract binary is not an option?

[marc0der]

It's a big pity, and we can always revisit this if they find a different way of repackaging their tools.

[helpermethod]

@overheadhunter The jextract guys made some changes to the distribution so that we should finally be able to publish EA builds.

PR incoming
#695

[overheadhunter]

Great news, looking forward to it!

[marc0der]

It would be great to test these binaries with a local install before we add jextract @helpermethod

[helpermethod]

It would be great to test these binaries with a local install before we add jextract @helpermethod

Tested the latest version on Ubuntu and it seems to work fine.

Directory structure fits, jextract binary is executable.

Looking at the extracted TAR, I wonder if the version shouldn't just include the OpenJDK version 🤔.

[marc0der]

Okay, so is it a tar archive? Do they have a zip variant? If it's only tar, we'll need to override it in the hooks service.

Looking at the extracted TAR, I wonder if the version shouldn't just include the OpenJDK version

We're you referring to the version in the containing folder?

[helpermethod]

Okay, so is it a tar archive? Do they have a zip variant? If it's only tar, we'll need to override it in the hooks service.

Looking at the extracted TAR, I wonder if the version shouldn't just include the OpenJDK version

We're you referring to the version in the containing folder?

Yes, it's only distributed as a TAR, so we also need to extend the hooks service.

[helpermethod]

@marc0der It seems you already made the necessary changes to the sdkman-hooks service a while ago

sdkman/sdkman-hooks@7781dcb

[marc0der]

Yeah, I was just rereading the thread above and saw it ☺️