openjdk: update to openjdk-21
Needs some testning, and we should likely add TERMUX_PKG_PROVIDES=openjdk and update the dependencies of packages that depend on openjdk(-17)
Are you sure it is a good idea to switch to pojav-based code? Even in that case probably it would be better to find diff make patches applicable to upstream code. Also. Does this remove opedjdk-17 and replaces it with openjdk-21?
Are you sure it is a good idea to switch to pojav-based code? Even in that case probably it would be better to find diff make patches applicable to upstream code.
Patches were cleaned up in https://github.com/termux/termux-packages/pull/15108, I have pushed them to our fork, to the termux/jdk-* branches that I build from here.
With cleaned up patches we are quite close openjdk/mobile (closer than pojav), so would probably be good to re-clone/update our openjdk-mobile-termux repo so that it looks like a fork from openjdk/mobile instead
Does this remove opedjdk-17 and replaces it with openjdk-21?
Yes, I pushed it in two parts to check CI on openjdk-17 update as well as openjdk-21. (The openjdk-17 update is a no-op since package is removed afterwards, but I would like go have it in got history in case we ever want to restore openjdk-17, or add it to TUR)
Patches were cleaned up in #15108, I have pushed them to our fork, to the termux/jdk-* branches that I build from here.
Would not it be better to squash all changes to patches? I mean with patches we can see what and where exactly is changed without trying to diff or git diff locally on PC.
since package is removed afterwards, but I would like go have it in got history
Should not we keep it for compatibility reasons?
Would not it be better to squash all changes to patches? I mean with patches we can see what and where exactly is changed without trying to diff or git diff locally on PC.
Yeah, there are some benefits, but we need around 40 patches with in total 2500 lines. I think that is a bit excessive for carrying in termux-packages. It is also easier to maintain if we carry the patches in a git repo, no need to git am && git format-patch all patches on
every change.
since package is removed afterwards, but I would like go have it in got history
Should not we keep it for compatibility reasons?
We tend to keep only one version of different packages (discussed in previous patch clean up PR as well), and openjdk-17 is quite old by now, we need to add another repo to the docker image to be able to build it. I think it would be better to add openjdk-17 to TUR, but we should indeed add an openjdk meta package, and make other packages depend on that one instead of openjdk-17 (or openjdk-19)
openjdk-17 should not be removed IMO, gradle and kotlin only recently added support for 21. There are likely android and java projects that itself wouldn't compile for 21, probably termux-app wouldn't either. Both kotlin and android gradle plugin (different from gradle) are also still fixing issues with jdk21. Moreover, older AGP versions wouldn't work either with jdk21. We should have both openjdk-17 and openjdk-21. openjdk-17 is used by default for building in a lot of different things, doesn't matter if its old, so is python2. Moreover, its unlikely to change a lot anyways, and its last commit was 3 years ago and repo is read only now, so wouldn't require much work to keep, other than rebuilds.
https://docs.gradle.org/8.5-rc-3/release-notes.html#java-21
https://developer.android.com/build/releases/past-releases/agp-8-2-0-release-notes
https://issuetracker.google.com/issues/294137077?pli=1
https://github.com/JetBrains/kotlin/releases/tag/v1.9.23
https://github.com/openjdk/jdk17
What is the current status of JDK21? It's possible to release a beta version for testing?
@nexplorer-3e There no beta version because all builds fail.
@nexplorer-3e There no beta version because all builds fail.
Well the 64bit builds in #20793 seem to have succeeded.
Yes, in different PR they are available.
Here is for "beta" test aarch64 link: https://github.com/termux/termux-packages/actions/runs/9826982880/artifacts/1674981006
I am astonished when almost no JDK Builds provide build for x86 and arm32. Liberica is an exception. If there is a need to keep the JDK up to date instead fix at one update version (or a commit), the final working package may come later (cause current type redefinition may be able to bypass with older UPDATE version)
I am fine with dropping this PR (or rather drop openjdk-21 part and just keep openjdk-17 simplification commits).
Will post some review comments in the other PR.
Any plans about possible JDK version management change?
Any plans about possible JDK version management change?
You mean script for choosing which java to set as default? I think that would be useful to users, yes. It doesn't have to be added at the same time as openjdk-21, though that would probably be best.
I can work on it, but might take a few weeks.
You mean script for choosing which java to set as default? I think that would be useful to users, yes. It doesn't have to be added at the same time as openjdk-21, though that would probably be best.
I can work on it, but might take a few weeks.
Arch has one, might be useful as a reference. https://wiki.archlinux.org/title/Java#Switching_between_JVM https://gitlab.archlinux.org/archlinux/packaging/packages/java-common/-/blob/main/bin_archlinux-java?ref_type=heads
You mean script for choosing which java to set as default? I think that would be useful to users, yes. It doesn't have to be added at the same time as openjdk-21, though that would probably be best. I can work on it, but might take a few weeks.
Arch has one, might be useful as a reference. https://wiki.archlinux.org/title/Java#Switching_between_JVM https://gitlab.archlinux.org/archlinux/packaging/packages/java-common/-/blob/main/bin_archlinux-java?ref_type=heads
Debian also have one, which the docs would be less than arch while more "one-click" flavor: update-alternatives-java
(Wondering why almost every distro making their own wheels)
Closing in favour of https://github.com/termux/termux-packages/pull/20793