Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

openjdk: add openjdk15 #100403

Closed
wants to merge 1 commit into from
Closed

openjdk: add openjdk15 #100403

wants to merge 1 commit into from

Conversation

raboof
Copy link
Member

@raboof raboof commented Oct 13, 2020

Motivation for this change

To have the latest JDK version available.

Support for darwin (of for 32-bit systems) is not included in this PR, but it seems useful already.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@taku0
Copy link
Contributor

taku0 commented Nov 23, 2020

Quick test:

  • AWT Hello World: OK
  • Swing Hello World: OK
  • JFX Hello World: OK
  • JFX MediaPlayer: Failed

Sample code: https://github.com/taku0/JavaSample/tree/4086d84efd8041d09f0075a9f7c6fe936553c130

@taku0
Copy link
Contributor

taku0 commented Nov 23, 2020

MediaPlayer doesn't work even with openjdk11.

@gytis-ivaskevicius
Copy link
Contributor

ping

@raboof
Copy link
Member Author

raboof commented Dec 1, 2020

MediaPlayer doesn't work even with openjdk11.

ok, so no regression there

ping

who are you pinging?

Rebased, ofborg seems happier now as well.

Note there has been some discussion around which Java versions to retire, see https://discourse.nixos.org/t/retirement-of-old-openjdk-releases/9929

@jerith666
Copy link
Contributor

I've looked this over somewhat, but haven't had time to try it locally. Still trying to find that time. :)

The only thing I noticed so far is: I don't think we ought to leave both jdk14 and jdk15 "exposed" in all-packages.nix -- jdk14 should be inlined as the bootstrap jdk for 15, nothing more. This way we only have one non-LTS jdk for people to choose from.

@raboof
Copy link
Member Author

raboof commented Dec 3, 2020

This way we only have one non-LTS jdk for people to choose from.

If we need to build it to bootstrap openjdk15 anyway, what is the advantage of not exposing it in all-packages.nix?

@jerith666
Copy link
Contributor

I'm not sure we want to maintain the approach of building an ever-growing chain of bootstrap jdks. It might make more sense to e.g. bootstrap with adoptopenjdk.

It's also the case that any explicit dependencies on jdk13 or jdk14 are just tech debt that's gonna come due in a pretty short timeframe (~6 mos, AIUI) -- when OpenJDK stops publishing updates to them, do we mark them insecure? Or remove them from all-packages.nix and update explicit dependencies to jdk15 etc.? We should try as hard as we can to avoid baking dependencies on short-lived projects into nixpkgs -- the goal of the new release cadence for OpenJDK, as I understand it, is to encourage quicker adoption of new releases by making them easier to digest, and I think a rolling-release package collection like nixpkgs is better off working with that cadence if at all possible.

Maybe I'm just being optimistic that serious breaking changes like JPMS will be few and far between ... :)

@raboof
Copy link
Member Author

raboof commented Dec 7, 2020

I'm not sure we want to maintain the approach of building an ever-growing chain of bootstrap jdks. It might make more sense to e.g. bootstrap with adoptopenjdk.

That is what we do, right? (except on i686 where adoptopenjdk is not available, according to the comment)

It's also the case that any explicit dependencies on jdk13 or jdk14 are just tech debt that's gonna come due in a pretty short timeframe (~6 mos, AIUI) -- when OpenJDK stops publishing updates to them, do we mark them insecure? Or remove them from all-packages.nix and update explicit dependencies to jdk15 etc.?

I would like to remove them - that was part of my motivation for #105924: if we can use that to easily fetch various JDK's for development purposes, dropping openjdk14 from the 'real' packages would not be a big deal anymore.

@jerith666
Copy link
Contributor

I'm not sure we want to maintain the approach of building an ever-growing chain of bootstrap jdks. It might make more sense to e.g. bootstrap with adoptopenjdk.

That is what we do, right? (except on i686 where adoptopenjdk is not available, according to the comment)

It's not what's done in this PR; it just does:

openjdk15-bootstrap = openjdk14;

@raboof
Copy link
Member Author

raboof commented Dec 9, 2020

I'm not sure we want to maintain the approach of building an ever-growing chain of bootstrap jdks. It might make more sense to e.g. bootstrap with adoptopenjdk.

That is what we do, right? (except on i686 where adoptopenjdk is not available, according to the comment)

It's not what's done in this PR; it just does:

openjdk15-bootstrap = openjdk14;

Ah, you're quite right, I was looking at the wrong one.

Anyway, I see adoptopenjdk 15 has made it into nixpkgs since, which is sufficient for my use case so I'll close this one.

@raboof raboof closed this Dec 9, 2020
@jerith666
Copy link
Contributor

I've resurrected this work in #107547.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants