openjdk-11, please?

[Harald Dunkel]

Hi folks,

google told me

No results found for site:lists.debian.org "openjdk-11" backport

so I wonder if such a backport could be added? Due to Oracle's license
change I would like to avoid the proprietary package on my Debian 9
hosts.


Regards
Harri

[Markus Koschany]

Hello Harri,

Post by Harald Dunkel
Hi folks,
google told me
    No results found for site:lists.debian.org "openjdk-11" backport
so I wonder if such a backport could be added? Due to Oracle's license
change I would like to avoid the proprietary package on my Debian 9
hosts.

Why do you need a backport of OpenJDK 11 for Stretch? OpenJDK 8 is fully
supported and works perfectly. We haven't even switched to OpenJDK 11 as
the default-jre in Sid. OpenJDK 11 would break a lot of packages at
runtime and even more packages would fail to build from source. I don't
think it would be really useful for most of our stable users and if you
are interested in bleeding edge Java software then you are better served
by using testing or sid.

Regards,

Markus

[Lee Garrett]

Post by Markus Koschany
Hello Harri,

Post by Harald Dunkel
Hi folks,
google told me
    No results found for site:lists.debian.org "openjdk-11" backport
so I wonder if such a backport could be added? Due to Oracle's license
change I would like to avoid the proprietary package on my Debian 9
hosts.

Why do you need a backport of OpenJDK 11 for Stretch? OpenJDK 8 is fully
supported and works perfectly. We haven't even switched to OpenJDK 11 as
the default-jre in Sid. OpenJDK 11 would break a lot of packages at
runtime and even more packages would fail to build from source. I don't
think it would be really useful for most of our stable users and if you
are interested in bleeding edge Java software then you are better served
by using testing or sid.

Not wanting to be picky, but you can actually install several openjdk versions
in parallel without switching the default one (the default-jre package depends
on that).

Also, there might be users that need newer software but aren't interested in
pulling the whole system to bleeding edge. So it's a matter of Harald bringing
up good arguments why openjdk-8 or 9 won't suffice, and someone with upload
rights backporting and maintaining it.

[Markus Koschany]

Am 18.10.18 um 17:31 schrieb Lee Garrett:
[...]

Post by Lee Garrett
Not wanting to be picky, but you can actually install several openjdk versions
in parallel without switching the default one (the default-jre package depends
on that).
Also, there might be users that need newer software but aren't interested in
pulling the whole system to bleeding edge. So it's a matter of Harald bringing
up good arguments why openjdk-8 or 9 won't suffice, and someone with upload
rights backporting and maintaining it.

I do understand the point of backports. However OpenJDK is not your
everyday leaf package, it provides the Java Virtual Machine that makes
your Java software compile and run. Why would you need another version
in Stretch that does actually the same thing? The reason why we only
focus on one OpenJDK version per release cycle is that we don't want to
provide security support for two Java Runtime Environments. All packages
in Stretch are well tested against OpenJDK 8 but certainly not for
OpenJDK 11. Without doubt there will be regressions if you try OpenJDK
11 on them. As a member of the Java team I can rule out that anyone
intends to maintain OpenJDK 11 in stretch-backports. But as you have
pointed out correctly, everyone can step up and do it.

[Harald Dunkel]

Hi Markus,

Post by Markus Koschany
Why do you need a backport of OpenJDK 11 for Stretch?

We are using Stretch for development and tests. Openjdk 11 is needed to
review the new features without switching to another platform. We
already skipped 9 and 10.

Post by Markus Koschany
OpenJDK 8 is fully
supported and works perfectly.

I cannot speak for openjdk8, but Oracle's Java 8 is not aware of cgroups,
for example. You have to use

-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

turning on other experimental features as well. Is this different for
openjdk8?


Regards
Harri

[Markus Koschany]

Hi,

Post by Harald Dunkel
Hi Markus,

Post by Markus Koschany
Why do you need a backport of OpenJDK 11 for Stretch?

We are using Stretch for development and tests. Openjdk 11 is needed to
review the new features without switching to another platform. We
already skipped 9 and 10.

Compiling OpenJDK 11 from source requires either OpenJDK 10 or OpenJDK
11 which makes it a bit difficult to backport to Stretch. It is not
impossible but you have to backport OpenJDK 10 first and adjust the
debian/control{.in} file for your Stretch environment.

I suggest to consider upgrading your test environment to testing which
has several advantages. Not only will you get the latest version of
OpenJDK 11, you will also have access to newer Java libraries and
applications. In addition you could help the Java team by reporting any
issues you find while testing with OpenJDK 11.

Post by Harald Dunkel

Post by Markus Koschany
OpenJDK 8 is fully
supported and works perfectly.

I cannot speak for openjdk8, but Oracle's Java 8 is not aware of cgroups,
for example. You have to use
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
turning on other experimental features as well. Is this different for
openjdk8?

It is most likely the same. As far as I know this feature was added in
OpenJDK 8u131 and improved in later versions of OpenJDK. If this is the
only reason why you need OpenJDK 11, enforcing proper memory limits in
containers, then setting up a new system with Debian testing is the
least amount of work IMHO.

Regards,

Markus

[Sven Hoexter]

On Thu, Oct 18, 2018 at 07:46:08AM +0200, Harald Dunkel wrote:

Hi,

Post by Harald Dunkel
google told me
No results found for site:lists.debian.org "openjdk-11" backport
so I wonder if such a backport could be added? Due to Oracle's license
change I would like to avoid the proprietary package on my Debian 9
hosts.

As others outlined in this thread the compilation of Java 11 is not so simple.
At work we decided to give the builds of the AdoptOpenJDK.net initiative a try.
If you trust those builds or not is something you've to decided.

For now we're just mirroring them internally and pull them into docker images
which is easy[1]. We're currently looking into extending my fork of java-package[2]
further to also support converting those binary builds to Debian packages. On the
other hand, if you just want to drop the jdk somewhere into /opt/jvm/jdk11 or something
like that, I guess you're faster with using a hammer like fpm to force it into a .deb.

Sven

[1] The Jenkins mirror job is just
curl -s https://raw.githubusercontent.com/AdoptOpenJDK/openjdk11-binaries/master/releases.json | \
jq -r ".[].assets[].browser_download_url" | \
grep -E "OpenJDK11.+x64_linux_hotspot"

+ downloading and checksum verification.

[2] https://git.sven.stormbind.net/?p=sven/java-package.git