Zulu is a build of OpenJDK by Azul. It's got a redistributable-friendly license, and it passes the Java TCK. The versions also match the related Oracle JDK releases. See http://www.infoq.com/articles/Gil-Tene-QA for more. Reproducible: Always
Which benefits do we get from supporting yet another Java Development Toolkit? There are already a bunch available in Portage: - OpenJDK (via IcedTea) - Oracle JDK - IBM JDK Adding yet another means: - more work - more maintenance - more troubles As far as I'm concerned, I see little to no benefit in adding Azul to the tree. Further, if "Zulu is a build of OpenJDK", why not using OpenJDK in this case?
This was all in the article I linked to, but I'll summarize here. - You can't just "compile OpenJDK" and get something useful. You need something that has passed the TCK. It's a big and complex codebase and you need just the right compiler version and flags to avoid getting weird thread safety issues and things like that. This is the value that IcedTea and Zulu provide: they've done the work of compiling it to pass the TCK. So, "using OpenJDK" isn't really an option. You need to use a precompiled binary. - Given that the binary choices for OpenJDK are IcedTea and Zul, why Zulu? Because IcedTea is super old. They don't have an OpenJDK 8 binary yet, but Java 8 came out almost a year ago. Zulu, meanwhile, has their releases out quickly after Oracle does (Oracle JDK 8u31 came out a few days ago, and Zulu 8u31 will be out in a few days). IcedTea is already almost irrelevant for Java devs, and is soon to be entirely so if they don't get their act together: Java 7 will be EOL'd in April 2015. - So, it's basically an equivalent to Oracle's JDK (i.e. passes TCK and up to date) that doesn't require the Oracle JDK's "fetch the file from the website" dance.
(In reply to wyvern5 from comment #2) > This was all in the article I linked to, but I'll summarize here. > I think describing it as an "article" is pushing things a little. It's an interview with someone who works for Azul, so clearly there is a bias in what is said. There seems to be a very strained argument to claim that Azul is the only OpenJDK 8 build, despite being presented with evidence that Fedora, RHEL and Debian also have such builds. Yes, u40 is not released yet. But they refer to Debian *unstable*; where else are new versions going to be tested out? Are Oracle also not to release early access builds of u40? In that spirit, I'll state clearly that I work on OpenJDK & IcedTea for Red Hat, so I'm also biased in favour of true FOSS solutions rather than the binary blobs Azul is providing. Looking at Azul's web page, I see an outdated build of OpenJDK (u25, the latest is u31) and no link to the source code. > - You can't just "compile OpenJDK" and get something useful. You need > something that has passed the TCK. It's a big and complex codebase and you > need just the right compiler version and flags to avoid getting weird thread > safety issues and things like that. This is the value that IcedTea and Zulu > provide: they've done the work of compiling it to pass the TCK. So, "using > OpenJDK" isn't really an option. You need to use a precompiled binary. > What exactly is your source for this nonsense? Users have been building IcedTea/OpenJDK on their Gentoo boxes for the best part of the decade. I don't know about the other Gentoo developers, but I've yet to see any reports of "weird thread safety issues". You seem to have completely misconstrued what IcedTea is. It's not a binary. It's a source-based distribution. Only binaries can be said to pass the TCK, and they obviously do so in a certain environment; the person running it will be using a certain desktop, certain libraries, etc. It's perfectly feasible for a Gentoo user to emerge IcedTea, license the TCK and run it themselves, but I'm not aware of anyone doing so as yet. This is likely to be a more valid result for their use than Azul's, because I doubt Azul ran the TCK on a Gentoo build with the exact same packages installed. Gentoo do provide a binary build of IcedTea, but this is not run against the TCK as far as I'm aware. It exists mainly to allow bootstrapping and easier installation on slower machines, much like the binaries for LibreOffice. Sadly, icedtea-bin doesn't provide for the cases where it would be most useful, which is on architectures such as ARM32 and PPC32, which are slower to build and have a more limited choice of JDK. Note that the TCK is proprietary and so it can't be discussed with anyone other than those who have also licensed it. > - Given that the binary choices for OpenJDK are IcedTea and Zul, why Zulu? > Because IcedTea is super old. They don't have an OpenJDK 8 binary yet, but > Java 8 came out almost a year ago. Zulu, meanwhile, has their releases out > quickly after Oracle does (Oracle JDK 8u31 came out a few days ago, and Zulu > 8u31 will be out in a few days). IcedTea is already almost irrelevant for > Java devs, and is soon to be entirely so if they don't get their act > together: Java 7 will be EOL'd in April 2015. There were IcedTea releases just the other week, so that's an interesting definition of "super old". As mentioned above, we don't do binaries so we never will have an "OpenJDK 8 binary". No, there isn't a final 8 source release yet, but that's because we want to do it right and not regress massively from our 7 releases. IcedTea provides many fixes above and beyond OpenJDK, notably in the area of support for using system libraries and a wider range of architectures. We could make a release based on OpenJDK as it stands, like Azul has, but we'd rather not be hit by a huge bunch of regression bug reports compared with IcedTea 2.x. There is an ebuild for IcedTea 3.x in the java overlay and you're more than welcome to test it out. We hope to do a u40-based release in a few months. As to "Java 7" being EOLed... No, Oracle's implementation will be EOLed, or rather, you'll have to pay money to get it, just like 6. The other reason work on 3.x / OpenJDK 8 is slow is because of the sheer amount of support requests we're still dealing with for both 6 & 7. This seems to suggest that the Java devs who indirectly pay my wages don't see it as irrelevant. > > - So, it's basically an equivalent to Oracle's JDK (i.e. passes TCK and up > to date) that doesn't require the Oracle JDK's "fetch the file from the > website" dance. I don't see this as a particularly strong reason to either support another JDK (and Gentoo seems already chronically understaffed on this front already) or switch from the Oracle JDK to a solution which lags behind noticeably on security updates. Of course, if you like it so much, you can easily just download it and use it yourself. However, Azul don't list Gentoo as a supported platform: http://www.azulsystems.com/products/zulu/specs and, these being binaries, they will need to link against the system libraries Azul used. This will probably mean that they contain duplicate copies of things like libjpeg, giflib, libpng, zlib, LCMS, etc. to maximise system compatibility (this is also true of Oracle's builds).
(In reply to Andrew John Hughes from comment #3) > I think describing it as an "article" is pushing things a little. It's an > interview with someone who works for Azul, so clearly there is a bias in > what is said. There seems to be a very strained argument to claim that Azul > is the only OpenJDK 8 build, despite being presented with evidence that > Fedora, RHEL and Debian also have such builds. Yes, u40 is not released > yet. But they refer to Debian *unstable*; where else are new versions going > to be tested out? Are Oracle also not to release early access builds of u40? Unstable is not the same as "not using released versions", which is what shipping "8u40" is at this point. Even Debian unstable typically ships libraries that have actually been released with a version... But, this isn't about what Debian does, so let's move on... > In that spirit, I'll state clearly that I work on OpenJDK & IcedTea for Red > Hat, so I'm also biased in favour of true FOSS solutions rather than the > binary blobs Azul is providing. Okay. Bias noted. > Looking at Azul's web page, I see an outdated build of OpenJDK (u25, the > latest is u31) and no link to the source code. I'm not saying anything about source code access. I do not care about that; it is built from the OpenJDK sources and I can go look at them there if I wish. As I said above, 8u31 is due to be released in a matter of days. It's not that I'm thrilled about the delay, but it's something I can live with, as the end result is useful to me. > > - You can't just "compile OpenJDK" and get something useful. You need > > something that has passed the TCK. It's a big and complex codebase and you > > need just the right compiler version and flags to avoid getting weird thread > > safety issues and things like that. This is the value that IcedTea and Zulu > > provide: they've done the work of compiling it to pass the TCK. So, "using > > OpenJDK" isn't really an option. You need to use a precompiled binary. > > > > What exactly is your source for this nonsense? Users have been building > IcedTea/OpenJDK on their Gentoo boxes for the best part of the decade. I > don't know about the other Gentoo developers, but I've yet to see any > reports of "weird thread safety issues". That's what I heard from Gil Tene (in personal meatspace conversation). Since he's a notable expert on the JDK, I'm inclined to take his word for it that things can go subtly wrong. Yes, he works for Azul. His bias is contrary to your bias. That doesn't make him incorrect. He builds JDKs for a living and sells them to people who push Java hard, so it doesn't surprise me that he may see more black swans than most. > You seem to have completely misconstrued what IcedTea is. It's not a binary. > It's a source-based distribution. Only binaries can be said to pass the TCK, > and they obviously do so in a certain environment; the person running it > will be using a certain desktop, certain libraries, etc. It's perfectly > feasible for a Gentoo user to emerge IcedTea, license the TCK and run it > themselves, but I'm not aware of anyone doing so as yet. This is likely to > be a more valid result for their use than Azul's, because I doubt Azul ran > the TCK on a Gentoo build with the exact same packages installed. I am not interested in doing TCK testing myself. I want someone else to do it for me. So, the fact that it is theoretically possible for me to do this is irrelevant to what I want, which is a binary that passes the TCK that has minimal dependencies on system-installed libraries and will be as identical as possible to what I'm deploying on my servers (which do not run Gentoo). > Gentoo do provide a binary build of IcedTea, but this is not run against the > TCK as far as I'm aware. It exists mainly to allow bootstrapping and easier > installation on slower machines, much like the binaries for LibreOffice. > Sadly, icedtea-bin doesn't provide for the cases where it would be most > useful, which is on architectures such as ARM32 and PPC32, which are slower > to build and have a more limited choice of JDK. > > Note that the TCK is proprietary and so it can't be discussed with anyone > other than those who have also licensed it. > > > - Given that the binary choices for OpenJDK are IcedTea and Zul, why Zulu? > > Because IcedTea is super old. They don't have an OpenJDK 8 binary yet, but > > Java 8 came out almost a year ago. Zulu, meanwhile, has their releases out > > quickly after Oracle does (Oracle JDK 8u31 came out a few days ago, and Zulu > > 8u31 will be out in a few days). IcedTea is already almost irrelevant for > > Java devs, and is soon to be entirely so if they don't get their act > > together: Java 7 will be EOL'd in April 2015. > > There were IcedTea releases just the other week, so that's an interesting > definition of "super old". As mentioned above, we don't do binaries so we > never will have an "OpenJDK 8 binary". Okay. So, IcedTea fulfills a different need then. I suppose what that means is that I am not interested in what IcedTea has to offer. I do not want either outdated binaries or current source. I want current binaries. > No, there isn't a final 8 source release yet, but that's because we want to > do it right and not regress massively from our 7 releases. IcedTea provides > many fixes above and beyond OpenJDK, notably in the area of support for > using system libraries and a wider range of architectures. We could make a > release based on OpenJDK as it stands, like Azul has, but we'd rather not be > hit by a huge bunch of regression bug reports compared with IcedTea 2.x. I view using system libraries as an anti-feature: it is exactly not what I want. Thus, I am not interested in IcedTea. That's great if that's what other users want, but my goal is to maximize what is shared between my dev box and my servers, and using system libraries is antithetical to that. > There is an ebuild for IcedTea 3.x in the java overlay and you're more than > welcome to test it out. We hope to do a u40-based release in a few months. My goal is to use a TCK-validated build. This is getting further from that goal. > As to "Java 7" being EOLed... No, Oracle's implementation will be EOLed, or > rather, you'll have to pay money to get it, just like 6. The other reason > work on 3.x / OpenJDK 8 is slow is because of the sheer amount of support > requests we're still dealing with for both 6 & 7. This seems to suggest that > the Java devs who indirectly pay my wages don't see it as irrelevant. People still pay Oracle to support Java 1.4 too. This argument is irrelevant to the broader Java community, who follow what Oracle supports publicly. This is not about what legacy-bound developers are willing to pay Oracle, or Gentoo, or Red Hat, or anyone else, to support. This is about what 90% of the world's Java developers use, which is the stuff that is freely available. > > - So, it's basically an equivalent to Oracle's JDK (i.e. passes TCK and up > > to date) that doesn't require the Oracle JDK's "fetch the file from the > > website" dance. > > I don't see this as a particularly strong reason to either support another > JDK (and Gentoo seems already chronically understaffed on this front > already) or switch from the Oracle JDK to a solution which lags behind > noticeably on security updates. Okay. Sorry we disagree about that. However, your needs are different from mine, apparently, and that's fine -- but I don't see why that means mine have to be excluded. > Of course, if you like it so much, you can easily just download it and use > it yourself. If it's easy to download and use, why is it a burden to have it be available in portage? > However, Azul don't list Gentoo as a supported platform: > > http://www.azulsystems.com/products/zulu/specs > > and, these being binaries, they will need to link against the system > libraries Azul used. This will probably mean that they contain duplicate > copies of things like libjpeg, giflib, libpng, zlib, LCMS, etc. to maximise > system compatibility (this is also true of Oracle's builds). Yes. That's a feature for me. I want it to bundle its own copy of libraries.
since Zulu has a decent JIT for ARM, and concidering the mess with Oracle, I guess it would be nice to have a zulu ebuild in portage. I'm using it already on my Raspberry Pi. And it works like a charm, while openjdk is defacto unusable (way too slow).
Hi For the time being, and most likely a long while, the Java team doesn't have the manpower to look after yet another JDK. For those interested in making Zulu available on Gentoo, here are two possible routes: * create a personal overlay containing the Zulu ebuilds for Gentoo. * maintain the Zulu ebuilds in the Portage tree through the Proxy Maintainer project [1]. Taking java@ off the CC list. Thanks! [1]: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
