+java

[vemonet]

At least OpenJDK ☕️

[mxcl]

refs

• https://github.com/Homebrew/homebrew-core/blob/master/Formula/openjdk.rb
• https://devqa.io/brew-install-java/

notes

We don't support casks (people will be welcome to create a pantry to do that, but the base tea will not). But potentially we can extract the files from the .pkg and create a bottle from that. Depends if java makes system changes or not.

[jonchang]

Note that java on macOS aarch64 has historically required a ton of patches to properly build (with tons of fun migrating patches for each new version), so it may not be possible to build "all the versions" without a lot of work. Extracting the files from the .pkg should work as long as we are careful about relocation and rpaths (java does some special stuff here which Homebrew didn't figure out until very recently)

[mxcl]

There's a reason other PMs don't “build all the versions”, certainly going into this I knew it would be a challenge. This may be one of the first to make that painful.

Yet! We'll try all the same!

[tnxz]

can't we have something like sdkman to do all the heavy lifting and tea magic script to wrap around it.

[mxcl]

@tnxz nice. As long as sdkman can give us something we can “bottle” then it's good for our current system.

Failing that we can package sdkman and recommend that (for now, a goal is ofc to pkg everything).

[tnxz]

so there is this github-actions https://github.com/sdkman/sdkman-action for sdkman can't we use it to directly package java somehow.

[mxcl]

I started openJDK #1337

[felipecrs]

I noticed this is already done by #2684

[mxcl]

it depends, is it possible to pkg java properly? We would need a license that allows redistribution and it would need to be pkg'd in a way that can be relocatable.

[felipecrs]

You can consider Eclipse Temurin (tea +adoptium.net/temurin) if you have trouble with the Oracle licenses. It's the most widely vendor-neutral free JDK and JRE distribution AFAIK.

Also, having a single version of Java available doesn't fit any dev env workflow. Would be nice to have automatic new versions for Java and past versions as well, preferably down to Java 8. :P

PS: I'm just saying it would be nice to have, and I know it's easy to say. Maybe someday I'll get my hands dirty on it.

[felipecrs]

What I am most missing from this right now is that only a few versions are available. It would be great to see more versions available, ideally automatic discovery/building like there is for golang, python and node.

[jhheider]

it's slightly trickier, since they're all different repos. that said, we can add any versions needed, assuming they're not insanely different to build (or if they are, but that takes more work).

[felipecrs]

Some versions I'd say are important, ordered by importance:

• 21 LTS (current latest LTS)
• 17 LTS (already pkged)
• 11 LTS
• 8 LTS (still used by tons of legacy software)

And also, I'd say it's ok if adding support for newer major versions has to be done manually (because of the new repo), but automatically building the patch releases for a given minor (autodiscovery of git tags) would be even greater.

[jhheider]

versions:
  # TODO: more majors
  - github: openjdk/jdk20u/tags
    # each repo contains all the prior repo tags at the time of the fork,
    # as well as tags like 20+10, which should be 20.0.0.10, but parses to
    # 20.10.0.
    transform: 'v => v.match(/jdk-20\.0\./) ? v.replace(/\+/, ".").replace(/^jdk-/, "") : undefined'
  - github: openjdk/jdk17u/tags
    transform: 'v => v.match(/jdk-17\.0\./) ? v.replace(/\+/, ".").replace(/^jdk-/, "") : undefined'

i believe we do currently build minors as they're tagged.

[felipecrs]

Oh. That's great! But there are a bunch of newer JDK 17 available already like 17.0.11.4 (https://github.com/openjdk/jdk17u/tags). I wonder what's going on then, because currently pkgx has only 17.0.10.6.

[jhheider]

probably a problem with our monitoring infrastructure. it uses some of brewkit's logic. i'll take a look. I can trigger the newest build now.

[felipecrs]

No, don't worry. I don't need it now.

EDIT: I see you did it already. Alright. Thank you!

[felipecrs]

I created a separate issue for Temurin btw: #5467

[felipecrs]

Now there is openjdk@21, openjdk@17, and openjdk@11.

openjdk@8 is indeed used by a lot of legacy software, but the main deal is that it cannot be compiled for Apple Silicon, and currently pkgx does not support limiting architectures depending on the version of a package (otherwise we would need to build a new separate package name).

So I think this issue can be closed now. We have an issue targeting temurin already and if someone (other than me 😅) requests openjdk@8 then we may consider supporting it.

[jhheider]

openjdk@8 is indeed used by a lot of legacy software, but the main deal is that it cannot be compiled for Apple Silicon, and currently pkgx does not support limiting architectures depending on the version of a package (otherwise we would need to build a new separate package name).

i'm perfectly happy if you want an openjdk.org/v8 project that only has x86-64 platforms. if you need it, others likely do as well.