Support Java non lts versions

[nhenneaux]

Is there any plan to support non LTS java version? It seems related to the Debian support of those if I properly understood?

https://github.com/GoogleContainerTools/distroless/issues/510

I found Java 18 in unstable sid branch. Is there any change to promote it to a gcr distroless image to support Java 18?

https://packages.debian.org/search?keywords=openjdk-18-jdk

Thanks for the help anyway

Nicolas

[loosebazooka]

Probably not. You could use Java-base and put the 18 jre on there and see if that works for you?

[georgespalding]

I suppose the answer is the same for Java 19? It seems the package is still unstable at the time of writing: https://packages.debian.org/search?keywords=openjdk-19-jre-headless

[loosebazooka]

Yeah, next supported version will probably be the next LTS version. We're working on making it easier for users to just build their own distroless images... maybe that'll help for situations like this.

[Sineaggi]

@loosebazooka node packages are picked up from upstream nodejs.org. Is there a chance that we could publish one of the vendors of java (be it oracle, azul, belsoft, amazon, microsoft etc) as the main set of java images, instead of the debian builds?

Or perhaps an additional image based on the 6-month support cycle builds from https://jdk.java.net/20/ for example?

As it stands we're down to java 17 on debian 12 only.

EDIT: Similar question for python as well, should we build images based on support upsteam python.org versions?

[sansnom]

@loosebazooka hello, still no plan to support non-LTS ? 😄

I was curious and try to check what work was required to add Java 22 java-22, it seems easy because it's well design. The only burden I see is the java_archives.bzl but as stated inside a comment, it could be generated with a script (from temurin API). I'm willing to take a look. If the issue is adding/removing, we could remove it when a new one is added. When 23 comes out, we can remove 22 at the same time. So keeping only LTS + 1 non-LTS. So it would require one change every 6 months.

Otherwise what the best course of action to maintain one ? You talked about making things easier to build your own distroless. You mean for example by using the base or java-base (but can't use java-base for temurin because it seems to be based on java_build_base which is not published) ? Or is it OK to use java-base (even if those lib are not needed libharfbuzz0b, libgraphite2-3, libglib2.0-0, libpcre, cacerts) ?

I saw one comment about rules_distroless but not yet ready to used right ? But I'm not sure how it would help in this case.

Note: I saw you also mentioned apko but not really distroless.

[sansnom]

I tried to reference gcr.io/distroless/java-base-debian12 in oci-image(base = "") but I don't think you can do that. So I'm not sure how we can easily use java-base from bazel. 🤔

I wonder if something stupid like that is not good enough for most people:

FROM alpine:latest AS build

RUN apk add tar
RUN apk add wget
RUN wget https://github.com/adoptium/temurin22-binaries/releases/download/jdk-22%2B36/OpenJDK22U-jre_x64_linux_hotspot_22_36.tar.gz
RUN tar -xzvf OpenJDK22U-jre_x64_linux_hotspot_22_36.tar.gz

FROM gcr.io/distroless/java-base-debian12:latest-amd64

COPY --from=build /jdk-22+36-jre /

[loosebazooka]

You might be able to use rules_distroless when it's ready. But we don't really have a good plan for supporting non-lts versions. This repo moves slow in general, and have 6 month turnovers might be an excessive burden. Once we move all our builds to temurin this should be easier. We'll publish java-build-base at that point. But again, the "GA" timeline for that is undefined.

[sansnom]

Ok, makes sense. Would there be anything wrong with the solution above using a Dockerfile and pulling gcr.io/distroless/java-base-debian12:latest-amd64 ? Thanks. 😄

[loosebazooka]

Seems fine to me. There may not be enough metadata for some scanners to pick it up if that's a concern?

[sansnom]

Ok, nice to know about scanner. There is just the difference of the few lib (which aren't present in java-build-base but present in java-base; plus the cacerts file). Not sure what would be the impact on that.

I will try to do the same with bazel by curiosity, seems doable to reference base-java as base in oci-image. https://github.com/bazel-contrib/rules_oci/blob/main/docs/java.md

[loosebazooka]

Yeah you can use rules_oci directly. And the apply the java tar on top of that image. We do it slightly different in this repository here: https://github.com/GoogleContainerTools/distroless/blob/main/private/remote/temurin_archive.bzl so that we can move some things around and add some sbom metadata. But, no reason you can't just ignore all our modifications and make it work for you.

[loosebazooka]

I think @dlorenc can point you to the wolfi jdk 22 image if you want a pre-built.

[dlorenc]

We have those images here: https://images.chainguard.dev/directory/image/jdk/versions

[davinkevin]

Very interested to help for non-LTS support too, and if I can help, let me know.

[loosebazooka]

We have no plans on including non-LTS version of Java in our builds.