tree-wide: migrate Java packages to JDK 21

[robertkirkman]

• Fixes Termux Maven Tied to Java-17 #25027

• JDK 21 has been released for a year, so theoretically, all packages should be ready now, but it will be necessary to test each package's basic functionality with openjdk-21 installed, to make sure that they are compatible.

• Now that fix(main/openjdk-{17,21}): adopt '.alternatives' system #25214 has been merged, it should be easier for termux-apt users whose java command is set to openjdk-17, to get it automatically updated to openjdk-21 without necessarily having to uninstall openjdk-17.

[robertkirkman]

openjdk-17 might still be desired for some 3rd party software, so it should remain available for a while still, but migrating reverse dependencies of it to openjdk-21 will be useful to solve issues like the one mentioned here.

[robertkirkman]

Working on Termux after using pkg install openjdk-21 and update-alternatives --set java $PREFIX/lib/jvm/java-21-openjdk/bin/java:

~ $ java --version
openjdk 21.0.7 2025-04-15
OpenJDK Runtime Environment (build 21.0.7)
OpenJDK 64-Bit Server VM (build 21.0.7, mixed mode)

• ant

ant test log

~ $ git clone https://github.com/jenkinsci/model-ant-project.git
~ $ cd model-ant-project/
~/model-ant-project $ ant
Buildfile: /data/data/com.termux/files/home/model-ant-project/build.xml

compile:
    [mkdir] Created dir: /data/data/com.termux/files/home/model-ant-project/build/classes
    [javac] Compiling 1 source file to /data/data/com.termux/files/home/model-ant-project/build/classes

jar:
      [jar] Building jar: /data/data/com.termux/files/home/model-ant-project/build/hello.jar

BUILD SUCCESSFUL
Total time: 0 seconds
~/model-ant-project $ 

• apksigner

apksigner test log

~ $ wget https://github.com/mkckr0/audio-share/releases/download/v0.3.4/audio-share-app-0.3.4-release.apk
~ $ apksigner verify audio-share-app-0.3.4-release.apk 
WARNING: META-INF/com/android/build/gradle/app-metadata.properties not protected by signature. Unauthorized modifications to this JAR entry will not be detected. Delete or move the entry outside of META-INF/.
WARNING: META-INF/version-control-info.textproto not protected by signature. Unauthorized modifications to this JAR entry will not be detected. Delete or move the entry outside of META-INF/.
WARNING: META-INF/androidx.activity_activity-compose.version not protected by signature. Unauthorized modifications to this JAR entry will not be detected. Delete or move the entry outside of META-INF/.
... (basically the same output as on PC)

• bdsup2sub: Unfortunately, I'm not sure how to get this package to work with either JDK or on PC I have found a way to successfully test this program.

bdsup2sub test log

I found out that bdsup2sub is a program for converting .sup files to .sub files. I don't exactly know what a .sup file is, but I found one in a random GitHub repository and I was able to convert it using bdsup2sub while using OpenJDK 21 without an error occurring, so I think this counts as a success.

~ $ wget https://github.com/EzraBC/pgsreader/raw/refs/heads/master/tests/MissionImpossible/MI-image52386.sup
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/data/data/com.termux/files/home/.wget-hsts'. HSTS will be disabled.
--2025-07-15 03:48:17--  https://github.com/EzraBC/pgsreader/raw/refs/heads/master/tests/MissionImpossible/MI-image52386.sup
Resolving github.com (github.com)... 140.82.113.4
Connecting to github.com (github.com)|140.82.113.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/EzraBC/pgsreader/refs/heads/master/tests/MissionImpossible/MI-image52386.sup [following]
--2025-07-15 03:48:18--  https://raw.githubusercontent.com/EzraBC/pgsreader/refs/heads/master/tests/MissionImpossible/MI-image52386.sup
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.111.133, 185.199.110.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 29253 (29K) [application/octet-stream]
Saving to: ‘MI-image52386.sup’

MI-image52386.sup              100%[====================================================>]  28.57K  --.-KB/s    in 0.005s  

2025-07-15 03:48:18 (6.10 MB/s) - ‘MI-image52386.sup’ saved [29253/29253]

~ $ bdsup2sub MI-image52386.sup MI-image52386.sub

Command line:
/data/data/com.termux/files/usr/share/java/bdsup2sub.jar MI-image52386.sup MI-image52386.sub 

Target frame rate set to 25fps

Converting SUB/IDX

Loading MI-image52386.sup
#> 1 (00:00:52.386)

Detected 0 forced captions.
WARNING: missing end time of frame 1 -> fixed
There was 1 warning

Writing MI-image52386.sub
Decoding frame 1/1 at offset 0x00000374

Writing MI-image52386.idx

Conversion of 1 file(s) finished
~ $ 

This software is very old. If someone is familiar with this software, and knows how to use this, it would be helpful if you could explain what to do!

• d8

d8 test log

~ $ d8 audio-share-app-0.3.4-release.apk 
~ $ file classes.dex 
classes.dex: Dalvik dex file version 035
~ $ 

• dex2jar

dex2jar test log

~ $ d2j-dex2jar classes.dex 
dex2jar classes.dex -> ./classes-dex2jar.jar
~ $ 

• gradle

gradle test log

~ $ mkdir testapp
cd testapp
yes | gradle init
gradle build

Welcome to Gradle 8.14.3!

Here are the highlights of this release:
 - Java 24 support
 - GraalVM Native Image toolchain selection
 - Enhancements to test reporting
 - Build Authoring improvements

For more details see https://docs.gradle.org/8.14.3/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)

> Task :init
Learn more about Gradle by exploring our Samples at https://docs.gradle.org/8.14.3/samples

BUILD SUCCESSFUL in 3s
1 actionable task: 1 executed
Calculating task graph as no cached configuration is available for tasks: build

> Task :buildEnvironment
Daemon JVM: Termux JDK 21.0.7
  | Location:           /data/data/com.termux/files/usr/lib/jvm/java-21-openjdk
  | Language Version:   21
  | Vendor:             Termux
  | Architecture:       amd64
  | Is JDK:             true


------------------------------------------------------------
Root project 'testapp'
------------------------------------------------------------

classpath
No dependencies

A web-based, searchable dependency report is available by adding the --scan option.

BUILD SUCCESSFUL in 10s
1 actionable task: 1 executed
Configuration cache entry stored.

• groovy

groovy test log

~ $ echo 'print "helloworld\n"' >  hello.groovy
~ $ groovy hello.groovy 
helloworld
~ $ 

• jython

jython test log

~/testapp $ jython -c "print 'hello'"
hello
~/testapp $ 

• kotlin

kotlin test log

~/testapp $ kotlinc hello.kt -include-runtime -d hello.jar -Dlibrary.jansi.path="$PREFIX/lib/jansi"
~/testapp $ java -jar hello.jar
hello world
~/testapp $ 

• libbcprov-java: Unfortunately, I don't know how to use it, but this build compiles it with JDK 21 without any error, so it can be assumed it should work at least as well as it does with JDK 17. It is a dependency of pdftk, so it can be assumed that the successfull test of pdftk should cover this.
• libcommons-lang3-java: same as libbcprov-java
• maven

maven test log

~/testapp $ mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.5 -DinteractiveMode=false
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/3.2.0/maven-clean-plugin-3.2.0.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/3.2.0/maven-clean-plugin-3.2.0.pom (5.3 kB at 16 kB/s)
... (a lot of messages)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  6.065 s
[INFO] Finished at: 2025-07-13T13:39:58Z
[INFO] ------------------------------------------------------------------------
~/testapp $ 

• pdftk

pdftk test log

~ $ wget https://ontheline.trincoll.edu/images/bookdown/sample-local-pdf.pdf
--2025-07-13 13:45:29--  https://ontheline.trincoll.edu/images/bookdown/sample-local-pdf.pdf
Resolving ontheline.trincoll.edu (ontheline.trincoll.edu)... 185.199.110.153, 185.199.111.153, 185.199.109.153, ...
Connecting to ontheline.trincoll.edu (ontheline.trincoll.edu)|185.199.110.153|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 49672 (49K) [application/pdf]
Saving to: ‘sample-local-pdf.pdf’

sample-local-pdf.pdf   100%[=========================>]  48.51K  --.-KB/s    in 0.02s   

2025-07-13 13:45:29 (2.01 MB/s) - ‘sample-local-pdf.pdf’ saved [49672/49672]

~ $ wget https://file-examples.com/storage/fe272c835c68711ef9aa603/2017/10/file-sample_150kB.pdf
--2025-07-13 13:45:34--  https://file-examples.com/storage/fe272c835c68711ef9aa603/2017/10/file-sample_150kB.pdf
Resolving file-examples.com (file-examples.com)... 104.21.64.1, 104.21.80.1, 104.21.48.1, ...
Connecting to file-examples.com (file-examples.com)|104.21.64.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 142786 (139K) [application/pdf]
Saving to: ‘file-sample_150kB.pdf’

file-sample_150kB.pdf  100%[=========================>] 139.44K  --.-KB/s    in 0.005s  

2025-07-13 13:45:35 (29.3 MB/s) - ‘file-sample_150kB.pdf’ saved [142786/142786]

~ $ pdftk file-sample_150kB.pdf sample-local-pdf.pdf cat output merged.pdf
~ $ 

• plantuml

plantuml test screenshot

• procyon-decompiler

procyon-decompiler test log

~ $ cat > Hello.java << 'EOF'
public class Hello
{
    public static void main(String[] args)
    {
        System.out.println("helloworld");
    }
}
EOF
~ $ javac Hello.java
~ $ procyon-decompiler Hello.
Hello.class  Hello.java   
~ $ procyon-decompiler Hello.class 
// 
// Decompiled by Procyon v0.6.0
// 

public class Hello
{
    public static void main(final String[] array) {
        System.out.println("helloworld");
    }
}
~ $ 

• scala: Unfortunately, I'm not great at Scala, so my Scala hello world is a bit wonky, I'm not sure why (I think scala Hello is supposed to work, but for me that shows [error] Hello is not a scala sub-command). It does the job for a basic test, though.

scala test log

~ $ cat > Hello.scala << 'EOF'
object Hello {
    def main(args: Array[String]) = {
        println("Hello, world")
    }
}
EOF
~ $ scalac Hello.scala 
~ $ scala --classpath . --main-class Hello
[warn] Jars with the *-sources.jar name suffix are assumed to be source jars.
The following jars were assumed to be source jars and will be treated as such: /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/test-runner_2.13/1.8.0/srcs/test-runner_2.13-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/runner_2.12/1.8.0/srcs/runner_2.12-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/test-runner_3/1.8.0/srcs/test-runner_3-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/runner_3/1.8.0/srcs/runner_3-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/test-runner_2.12/1.8.0/srcs/test-runner_2.12-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/runner_2.13/1.8.0/srcs/runner_2.13-sources.jar
[warn] Jars with the *-sources.jar name suffix are assumed to be source jars.
The following jars were assumed to be source jars and will be treated as such: /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/test-runner_2.13/1.8.0/srcs/test-runner_2.13-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/runner_2.12/1.8.0/srcs/runner_2.12-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/test-runner_3/1.8.0/srcs/test-runner_3-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/runner_3/1.8.0/srcs/runner_3-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/test-runner_2.12/1.8.0/srcs/test-runner_2.12-sources.jar, /data/data/com.termux/files/home/.cache/scalacli/local-repo/1.8.0/org.virtuslab.scala-cli/runner_2.13/1.8.0/srcs/runner_2.13-sources.jar
Hello, world
~ $ 

[robertkirkman]

agnostic-apollo, because you explained in 2024 that at the time, many things still depended on openjdk-17, I just need to know whether your current opinion on the topic is compatible with my new PR:

• openjdk: update to openjdk-21 #19682 (comment)

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.

Here is a recap of what has changed since then:

• the openjdk-17 package in Termux is no longer "frozen", and has received some bug fixes and updates that include closely aligning its build settings with the openjdk-21 package and changing its upstream source repository to https://github.com/openjdk/jdk17u/, which receives many of the same bug fixes and security updates from upstream that the "jdk21u" repository does, but for JDK 17 instead of JDK 21
• During the same series of fixes, it has become easier for users to properly switch between the java command providing openjdk-17 and openjdk-21, because of a recent PR fixing janky behavior of the update-alternatives --config java command where, for example, man pages were not always synchronized with the correct provider of commands java, javac, man java, man javac, etc.
• I have now run at least one successful test on openjdk-21 of every package that still depends on openjdk-17 in the termux-packages repository, including both gradle and kotlin. I have not tested Android Gradle Plugin, but OpenJDK 21 has been default on the Ubuntu cross-compiling docker image since it was upgraded to Ubuntu 24.04, and as far as I am aware, Android Gradle Plugin is not an officially packaged or supported plugin in the gradle package of Termux.
• JDK 25 LTS will come out in September 2025 and I have a working, WIP rough draft of patches for it saved to prepare, and since all packages have been tested with JDK 21 and confirmed to work with it, it would be convenient and easier to keep track of the status of each package if, at the moment JDK 25 were added, all packages started out uniformly depending on JDK 21, and could then be migrated to JDK 25 one by one as needed.

Here is a recap of what this new PR would do:

• It would orphan openjdk-17 by moving all reverse dependencies of openjdk-17 to depend on openjdk-21 instead
• It would automatically switch the java command of all users who received openjdk-17 purely automatically as a dependency of one of these packages, to openjdk-21, and allow them to remove openjdk-17 using apt autoremove. This part would fix Termux Maven Tied to Java-17 #25027 .
• It would not remove openjdk-17 or remove it from the java command of users who have manually selected openjdk-17 as their java command explicitly using the update-alternatives command
• It would not work on termux-pacman currently, which has some problems with alternatives at this time. Solutions to these problems are WIP. Merging this PR before a solution to [Bug]: [pacman] pager: No such file regression (git-2.50.0-1) #25263 is merged, could unfortunately exacerbate the termux-pacman issue and spread it to more termux-pacman users, so that issue should probably be solved separately before this PR is merged. EDIT: termux-pacman has pinned an older version of the openjdk packages for now from before the issue was introduced, so this PR can move forward without affecting termux-pacman, which will get the updates on its own schedule.