OpenJDK 12 no longer usable

Languages Java
21

Yes, thanks, my builds are back to green!

I saw the conversation on the bug and on Twitter. The current situation looks kind of fragile: Travis is using a (great) script from @ sormuras meant to “provide access to the latest and greatest GA OpenJDK” to get access to basically any existing JDK.
In turns, it downloads form oracle / javanet / other servers.
If anything goes wrong on those servers, builds fail.
If the script needs an update, builds generally fail in the meantime (work-around-able, but not really a solution).

If the OpenJDK licensing allows for it, it might make sense hosting “fallback” copies of the JDKs on Travis servers, or pre-install them in the Travis image (I don’t know whether that’d be a cost). Do you think there could be ways to make the java based jobs more resilient to changes or failures on the oracle / openjdk side, on which I think we have no control at all?

1 Like
22

Using containers from docker.com could be a solution: https://twitter.com/fedor/status/1122886194608640000

23

Wow, nice.
But still, from a user perspective, I’d expect to be able to list the JDKs I want to support, and have them running (as they usually do). It’s very appealing to have such machinery work with minimal configuration.

I also teach CI and SE practices, multi-jdk builds are a nice way to show how things can stop working with upgrades (e.g. illegal reflection accesses with modules) or require backports to keep going, or even custom environment detection.

Having to setup Docker adds a layer of unwanted complexity, it’d be nice to be able to reliably use the wondrously simple configuration of the Travis documentation.