What to do about jdk?

[jakobvase]

Java development environments are complex. There are several runtimes available (openjdk, zulu, temurin, many more...), and while they all support almost everything, there are edge cases where something can run on one but not the other, a hotfix is pushed to one but not another etc.

For packages that depend on java (eg ktlint), it becomes messy to define their dependencies (openjdk.org || adoptium.net || ... - and we can't write this yet). What can we do about this?

Stackoverflow question with some good answers regarding this: https://stackoverflow.com/questions/61335109/what-is-the-difference-between-azul-openjdk-zulu-openjdk-and-openjdk
Medium article about this: https://medium.com/@javachampions/java-is-still-free-2-0-0-6b9aa8d6d244

[jakobvase]

One option is to enable using a package without its dependencies or without a specific dependency. That way we can say 'pkgx supports openjdk by default, but you can disable that if you want to use another distribution'.

Another option is to special case jdk. So a package can specify that it needs 'java^18', and if java is already available, it doesn't fetch anything.

[jhheider]

Another option is to special case jdk. So a package can specify that it needs 'java^18', and if java is already available, it doesn't fetch anything.

^ was the original plan for C compilers, but it was always slightly weird. one possibility is to have a jdk-shim package which looks for java already in the environment, and uses openjdk otherwise. as we know from our other shims, this can add 50 to a couple 100 ms to the invocation.

[jakobvase]

Interesting. Would it be possible to only run that shim on adding the package to the environment? dev off && dev on?

[jhheider]

if you were going to do it that way, you'd make every java dependency a jdk-shim: ^{{version.major}}. then, when something brought it into environment by any method, its attempts to call java, javac, etc would check for existing binaries before trying exec pkgx $1 -- "$@"