Zulu or OpenJDK for Java 8 on Debian?

[Kevin Burton]

I'm curious what you guys are using for Java 8 on Debian. 

I'd prefer not to use the Oracle binaries ... but I guess I can just be pragmatic.

There's also Zulu:

http://www.azulsystems.com/products/zulu/downloads#Linux

But it says it requires glibc 2.5 which I think is weird because glibc 2.20 is the latest... 

I guess this is just weird/wrong floating point comparison though 2.5 is < 2.20 ... 

[Ishaaq Chandy]

Curious - why do you prefer OpenJDK to the Oracle binaries? We use the Oracle binaries but only for historical reasons and since it requires additional shenanigans to install it on Debian/Ubuntu I have been wondering of late whether we should switch and am interested what others do on this list. i.e., other than licensing and/or installation issues, are there any functional/performance reasons to prefer one over the other?

Ishaaq

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gil Tene]

AFAIK, Zulu is your only real choice for an actual OpenJDK 8 binary on Debian right now.

Zulu is a fully tested, compatibility verified, and trusted binary distribution of OpenJDK 8/7/6. It is freely downloadable and freely redistributable.

To my knowledge, Zulu is currently the only OpenJDK 8 binary build available that is actually fully tested. When I say "actually fully tested", I mean that someone actually states that the specific binary package has passed the full set of OpenJDK TCK tests, and is verified to be a compatible and complaint implementation of the Java SE 8 spec. Azul certifies this for each Zulu binary package.

So for Java 8 (right now) your choices are OpenJDK (via the Zulu binary distros) or Oracle JDK. Both are well tested, compatibility-verified JDK 8 binaries. And both are available for Linux, Windows, and MacOS.

And no, that thing called "openjdk-8-jdk" that you would unfortunately get when you do an apt-get from the experimental or sid debian repos is not a good OpenJDK build. It currently appears shows as 8u40, which is something that doesn't actually exist yet. OpenJDK 8u40 is schedule to come out in March, and anything called "8u40" right now (without clear early access indicators) is certainly not a good release of anything.

You can see the specific example apt-get sequence for getting the OpenJDK8 (8u25) version of Zulu included in this dockerfile: 

https://github.com/zulu-openjdk/zulu-openjdk/blob/master/debian/8u25-8.4.0.1/Dockerfile

But it says it requires glibc 2.5 which I think is weird because glibc 2.20 is the latest... 

I guess this is just weird/wrong floating point comparison though 2.5 is < 2.20 ... 

 

The requirement is for glibc 2.5 of later. And yes, 2.20 is much later, so it's good.

The fact that Zulu is carefully built to support glibc versions all the way back to 2.5 is an example of the attention on compatibility testing I mention above. Zulu works across a wide array of linux distros, and glibc version vary across those. E.g.:

- RHEL 7 uses glibc 2.17. RHEL 6 uses glibc 2.12, and RHEL 5 uses glibc2.5 (same goes for matching CentOS versions).

- Ubuntu 14.04 LTS uses glibc 2.19, Ubuntu 12.04 LTS uses glibc 2.15

- Debian wheezy (7.0) uses glibc 2.13, and Debian squeezy (6.0) uses glibc 2.11.2. 

With such a wide range of versions, a not-so-careful and not-really-tested build of OpenJDK could easily end up with some nasty runtime surprises... So unless you really need to build your own stuff from scratch, Zulu is there to give save you worries and potential aggregation. Zulu's main value for the Java community is in providing a well build and well tested, and trusted binary build of OpenJDK, across multiple common platforms.

And it's free.

HTH.

[Ishaaq Chandy]

Interesting, good to know -  I'll rephrase my question then, what are the functional advantages of using Zulu over Oracle JDK? Or is it just non-functionals like licensing that would make one prefer the OpenJDK based Zulu over Oracle JDK?

Ishaaq

--

[Gil Tene]

Zulu (and any other proper OpenJDK build) has no functional or performance advantages or disadvantages when compared to the Oracle JDK of a matching version. The two are pretty much build from the same sources, licensed under (very) different terms. I would expect pretty much all measurements comparing the two to show "equal to within measurement noise". That's certainly what we've seen whenever a comparison was done.

<disclaimer: "I am not a lawyer">

The licensing advantages of Zulu (and other OpenJDK builds) is very real, and goes well beyond "I want to support and use open source": Zulu is not only free to use. It is freely redistributable. This means that you can safely include a full JDK in packages, guest OS images, docker images, AMIs, etc., and you don't have to worry about redistribution of those bits (e.g. by placing them in a public repository or letting someone else download them from a repo) crossing the commercial license terms and restrictions on redistribution that other JVMs may include with.

I can't speak for others and their licenses, but I'm pretty sure that hiding a script that downloads a free (but not freely redistributable) JDK and auto-answers "yes" to it's license questions without the third party end user actually knowing that a license is being accepted on their behalf is a no no. Sort of like signing someone else name on a check. For an example of something that is probably not a good idea to to be given to third parties, see this dockerfile. Zulu doesn't have that restriction, and you can use docker file like this one without worrying about redistribution restrictions and hidden license acceptance.

</ "I am not a lawyer" disclamer> 

And if you are looking for better functionality and behavior metrics, a kick-ass JVM, and benefits like putting an end to GC tuning and code-arounds, or ReadyNow warmup benefits, thats where Zing (Azul's flagship product) comes in. Think of Zulu as a "vanilla OpenJDK", while Zing is a banana split with a cherry on top.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Tobias Lindaaker]

Can anyone answer what other proper OpenJDK builds exist?

Our company is working on being more strict about which JVM versions we officially support. I am trying to argue that we should limit this to builds that we know satisfy some minimum level, a level that I would like to include passing the JCK for example. The alternative I'm trying to argue against is let's focus on what our customers actually use, which as gathered from usage metrics is the default openjdk-7-jdk from Ubuntu (version unspecified).

Since I don't have any insight into Ubuntus OpenJDK build process, I don't know if this is a build I'd trust. On the one hand I've found indications online that it is based on the OpenJDK build from RedHat, and other source tell me that RedHat has licensed the JCK. On the other hand, I can't find anything that actually states that the Ubuntu OpenJDK builds are certified compatible, and I know that at least a few years ago the Java build process for Debian was a complete mess (the former java package maintainer for Debian that I spoke to said he would never trust the Debian OpenJDK builds as they were at the time).

Thanks,

Tobias

Apologies if this email reaches you multiple (up to 3) times. Apple's Mail.app kept insisting on using the wrong address for sending my reply. It used an address other than the one that I am subscribed to this list with, despite me explicitly specifying this address to be used. I'm now falling back to the web-based gmail interface.

On Fri, Jan 9, 2015 at 8:43 AM, Gil Tene <g...@azulsystems.com> wrote:

Zulu (and any other proper OpenJDK build) has no functional or performance advantages or disadvantages when compared to the Oracle JDK of a matching version. The two are pretty much build from the same sources, licensed under (very) different terms. I would expect pretty much all measurements comparing the two to show "equal to within measurement noise". That's certainly what we've seen whenever a comparison was done.

<disclaimer: "I am not a lawyer">

The licensing advantages of Zulu (and other OpenJDK builds) is very real, and goes well beyond "I want to support and use open source": Zulu is not only free to use. It is freely redistributable. This means that you can safely include a full JDK in packages, guest OS images, docker images, AMIs, etc., and you don't have to worry about redistribution of those bits (e.g. by placing them in a public repository or letting someone else download them from a repo) crossing the commercial license terms and restrictions on redistribution that other JVMs may include with.

I can't speak for others and their licenses, but I'm pretty sure that hiding a script that downloads a free (but not freely redistributable) JDK and auto-answers "yes" to it's license questions without the third party end user actually knowing that a license is being accepted on their behalf is a no no. Sort of like signing someone else name on a check. For an example of something that is probably not supposed to be given to third parties without, see this dockerfile 

[Gil Tene]

Azul certifies each and every Zulu binary package we distribute (e.g. http://www.azulsystems.com/sites/default/files/pdf/cert.zulu1.8.0_25-8.4.0.1-x86lx64.zip.pdf). Zulu currently ships the latest OpenJDK 8, 7, and 6 versions.

I can't speak for RedHat, but I believe that IcedTea binaries are fully tested against the OpenJDK TCK before they are distributed.

(there are OpenJDK 6 and OpenJDK 7 versions of IcedTea, but AFAIZk no OpenJDK 8 version yet).

You can find the list of companies/entities that have a license to run the OpenJDK TCK tests here: http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html . Given the fact that the OpenJDK TCK license doesn't allow testing on behalf of someone else (std IANAL disclaimer applies), only binaries produced by those signatories could actually have been tested for TCK compatibility. Being on the list doesn't mean the binaries are properly tested, but not being on it is a guarantee that they are not..,

I don't really know what the process for Ubuntu OpenJDK packages (in the default repo) is like. I've heard it is build straight from source, but I don't know if OpenJDK TCK tests are performed in the actual release process.

When someone says "a built is based on X", I'd be very careful to check what that actually means. If it means "a redistribution of the exact binary package produced by X", it may very well be good (presuming X actually tested the binary). However, if it means "built from the same sources that X used to produce some other binaries" it could go wrong in 79 different ways. Ranging from use of a "wrong" gcc version (one that is missing a bug that is relied in a way that makes some TCK tests fail) to missing files or classes in the package. A from-source reproduction is good for playing around with, but unless the actual binary result of the build and packaging process was tested, I wouldn't trust it for production it official support.

The OpenJDK TCK includes several tens of thousands of tests. And when subtle build issues arise, they  sometimes cause only a handful of those tests to fail... 

Sent from Gil's iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "mechanical-sympathy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mechanical-sympathy/jQGahuzJKM4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mechanical-symp...@googlegroups.com.

[Ka-Hing Cheung]

This is totally awesome! Any chance the ubuntu package could include the proper jinfo file so update-java-alternatives would work?

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Richard Warburton]

Hi,

This is totally awesome! Any chance the ubuntu package could include the proper jinfo file so update-java-alternatives would work?

Are you sure this is a problem? I have zulu installed on my Desktop and update-alternatives works for me and there's a jinfo file in the bin directory.

regards,

  Richard Warburton

  http://insightfullogic.com

  @RichardWarburto

[Ka-Hing Cheung]

Ah we are talking about different jinfo files. update-java-alternatives look at  /usr/lib/jvm/.<jname>.jinfo to figure out how to switch all of java/javac/jar all at once.

--