Java 9

[cjander]

are there plans to support JDK 9 as well, maybe as a separate docker image?

[hjacobs]

Yes, we should support JDK 9! :smile:

I would not "hack" something now, but wait for some official .deb package for our Ubuntu LTS base image (might be some backport).

[hjacobs]

Oh, the package already exists :tada:

$ apt-cache show openjdk-9-jdk
Package: openjdk-9-jdk
Priority: optional
Section: universe/java
Installed-Size: 57
Maintainer: OpenJDK Team <openjdk@lists.launchpad.net>
Architecture: amd64
Source: openjdk-9
Version: 9~b114-0ubuntu1
Provides: java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk, java7-sdk, java8-sdk
Depends: openjdk-9-jre (= 9~b114-0ubuntu1), openjdk-9-jdk-headless (= 9~b114-0ubuntu1), libc6 (>= 2.2.5)
Recommends: libxt-dev
Suggests: openjdk-9-demo, openjdk-9-source, visualvm
Filename: pool/universe/o/openjdk-9/openjdk-9-jdk_9~b114-0ubuntu1_amd64.deb
Size: 16606
MD5sum: 50cac7eb7e843a79228b9be46c0cce6b
SHA1: ed1e69ebbb05be4bbb67b17f2c37f566f1b45ba7
SHA256: e34c6532c958b721a9d284873617dae1f96f718a2fe1ddfbec6667e05a78bc92
Description-en: OpenJDK Development Kit (JDK)
 OpenJDK is a development environment for building applications,
 applets, and components using the Java programming language.
Description-md5: b9e7f4837238c34971e4a8b72ab7d045
Multi-Arch: same
Homepage: http://openjdk.java.net/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

[hjacobs]

OK, the Ubuntu 16.04 universe package is really outdated (b115 from 2016).

[lalib]

When can it be ready to use? @hjacobs

[otrosien]

here is an example of installing openjdk9 on ubuntu docker: https://github.com/hrytsenko-sigma/ping/commit/fb146563e1e1a634b4e5b26cc1767c11c9f31690

[otrosien]

Alternatively one could use the java9 package from azul systems. I personally haven't tried them, but I heard that they're doing a better job in keeping their releases up-to-date than most official distros do.

see http://zulu.org/zulu-community/zuludocs/

[vroldanbet]

@hjacobs I created https://github.com/zalando-stups/docker-ubuntu/pull/18 I assume then we could provide openjdk 9

[vroldanbet]

forget last comment. 17.04 is no LTS :(

[vroldanbet]

@hjacobs given packages are not updated in 16.04, are we blocked until 18.04 LTS is released?

[hjacobs]

@vroldanbet if some backported and supported package exists, I would be fine with it.

Actually I'm no longer so sure about Java 9 as it seems to be only supported until March 2018, see http://www.oracle.com/technetwork/java/eol-135779.html

[vroldanbet]

@hjacobs indeed, weird move https://latesthackingnews.com/2017/09/11/oracle-will-not-give-java-9-ltslong-term-support

[jcranky]

So until 18.9 it seems Java 9 is still, in practice, beta software XD

[dmytro-vynokurov]

@vroldanbet this short talk by Mark Reinhold and Brian Goetz may provide more details on the java versioning updates.

Summarizing the talk, it is better to update to a new java version as soon as it gets released and not to wait for the LTS java release, since it may be harder to migrate then. Apart from this, with every new release we get a bunch of new features that make our life easier.

@hjacobs let's say we find a way to put openjdk 9 into a docker image. Do you think it would make sense to change the image tagging and versioning convention?

Now there is a single docker image tag (registry.opensource.zalan.do/stups/openjdk) and image version includes the java version. At the same time some people are just getting the latest version of the openjdk image. This may lead to the situation when someone will implicitly upgrade from java 8 to java 9 simply because java 9 image was built later.

I'm also wondering whether you consider building openjdk from sources a hacky solution?

[hjacobs]

@dmytro-vynokurov the version scheme change probably relies on the potential risk/impact of an OpenJDK upgrade, "in theory" the impact is small (using Java 8 to run Java 7 is also relatively safe).

Maybe building from source is a viable alternative, but I would prefer some maintained upstream package :smirk:

[harti2006]

I would prefer to have a different artifact name for Java 9, e.g. "registry.opensource.zalan.do/stups/openjdk9". Reason: I fear most of our applications will just stop working because with Java 9 one suddenly needs to add all used modules of the standard library explicitly when running the jar. As an example: to run a simple Spring Boot Web app, you now need: java --add-modules java.xml.bind jar app.jar

[cjander]

@harti2006 true, should be a different artifact. most of our applications are using “openjdk:latest”. so just adding java9 as new version here would most properly break most of our applications. Since the release cycle for java in general changed (way more often major releases), we should find a handy solution. like naming them openjdk9, openjdk10 and so on

[hjacobs]

TL;DR – Stay on Java 8, the current LTS release, until the next LTS release occurs (Java 11) ... or live with the downsides.

http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html

[whiskeysierra]

Stay on Java 8, the current LTS release, until the next LTS release occurs (Java 11) ... or live with the downsides.

I'm torn between agreeing or fighting this. :+1: :-1:

[jcranky]

Fight how? That seems very factual to me.

[whiskeysierra]

Because I want to be able to use the latest jdk version, but without official support from a zalando base image, I don't see this happening easily.

[tobr]

I would also disagree with staying at Java 8. There are a lot of benefits in Java 9 (and I'm not talking about the module system) and early adoption also leads to early adoption of the new features in java 10 and later on 11.

[nmeyer-zalando]

TL;DR – Stay on Java 8, the current LTS release, until the next LTS release occurs (Java 11) ... or live with the downsides.

The downsides are having to upgrade more frequently and having to stay on top of new Java releases. Call me crazy but I'd call that desirable in an agile organization.

[duergner]

From a DevOps perspective, I'm more in favor of staying with Java8 at the moment actually. Having to test your whole toolchain and dependencies every six months for potential breaking changes sounds like quite some overhead.

Especially with our setup which does not enforce at all a common technology stack. This will basically mean each and every one of our teams will spend at least 1-4 weeks every half year ensuring upgrades will not break their existing systems.

[dmytro-vynokurov]

I don't think that we need to make a decision at the organization level whether or not to use only LTS releases. Even more, single team may want to run some of the applications on the LTS release (those that are not updated often) and keep some other apps on the bleeding edge of technology if they work with these apps on a daily basis.

For such teams it would be really beneficial if Zalando could provide some kind of supported infrastructure, such as docker images with latest java version. Otherwise they will probably end up creating docker images with java 9 or 10 themselves, which is likely to be more error prone comparing to images created in a centralized way.

[alexkops]

I think I'll just leave this here, looks like from JDK10 on the "java-dynamic-memory-opts" hack is no longer neccessary? http://jdk.java.net/10/release-notes

The JVM has been modified to be aware that it is running in a Docker container and will extract container specific configuration information instead of querying the operating system. The information being extracted is the number of CPUs and total memory that have been allocated to the container. The total number of CPUs available to the Java process is calculated from any specified cpu sets, cpu shares or cpu quotas. This support is only available on Linux based platforms. This new support is enabled by default and can be disabled with the JVM option (-XX:-UseContainerSupport).

[hjacobs]

Closing in favor of #20.