Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mystery meat OpenJDK builds strike again

mail.openjdk.java.net

Post reply on HN
Print view View original

1–10 of 56 posts

Re: Mystery meat OpenJDK builds strike again

#2

Post by chungy »

As an observer, not any kind of authority:

The release methodology of OpenJDK from Oracle is obscure at best, and it is hard to imagine how package managers are supposed to cope. I notice both of these examples come with Debian version strings attached, and they likely build from tags in the version control repository. As example, in these two links:

https://hg.openjdk.java.net/jdk8u/jdk8u/tags

https://hg.openjdk.java.net/jdk-updates/jdk11u/tags

The "-ga" tags do pretty clearly delineate official releases, but they also get pushed to the public repository well (often weeks) after Oracle posts official binaries for these releases. It is confusing and makes it not all that mysterious that distribution packaging will take the best that they can see for doing a clean build, as they like to do.

It would help quite a lot if the +1/+2/+3/etc releases were instead delineated with "-alpha1", "-beta1", "-rc1" tags. Much clearer that they aren't meant to be production.

Re: Mystery meat OpenJDK builds strike again

#3

Post by CaliforniaKarl »

A few emails later in the thread[0], it is noted...

> ...who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK.

That, I think, is the main problem.

[0]: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0...

Edit: Actually linking to source (which I should've done from the beginning…)

Re: Mystery meat OpenJDK builds strike again

#6

Post by CaliforniaKarl »

ars wrote: post #4

There don't seem to be any debian emails about it: https://lists.debian.org/debian-java/2019/05/threads.html

The place where you'd want to look is the Debian Package Tracker entry for the source package, openjdk-8.

Here's the URL: https://tracker.debian.org/pkg/openjdk-8

That has the current status of the package, and links to the bug tracker, which is where I'd expect things to appear!

Re: Mystery meat OpenJDK builds strike again

#7

Post by CaliforniaKarl »

Unrelated, but one thing that's confused me, as someone who doesn't really use Docker.

I don't think of a programming language as being the thing upon which I would base my layers of containers. My expectation, as someone coming from not-containers, would be that I should first start with a core-libraries container, _then_ a language container, and then packages on top.

Having this clarity of composition, I think, is important if I need to start bringing other stuff into the environment, particularly stuff that requires compilation, so that I know what to target it against. It also makes it easier to know when a layer needs to be upgraded, for example because of a security issue.

The downside I see is that maintainers of layers higher up in the stack would possibly have to build multiple variants of their layer. But maybe that wouldn't be too big of a problem?

Re: Mystery meat OpenJDK builds strike again

#8

Post by chrisseaton »

CaliforniaKarl wrote: post #7

Unrelated, but one thing that's confused me, as someone who doesn't really use Docker. I don't think of a programming language as being the thing upon which I would base my layers of containers. My expectation, as someone coming from not-containers, would be that I should first start with a core-libraries container, _then_ a language container, and then packages on top. Having this clarity of composition, I think, is…

Core library of what programming language, if you haven't picked a language yet?

Re: Mystery meat OpenJDK builds strike again

#9

Post by emef »

CaliforniaKarl wrote: post #7

Unrelated, but one thing that's confused me, as someone who doesn't really use Docker. I don't think of a programming language as being the thing upon which I would base my layers of containers. My expectation, as someone coming from not-containers, would be that I should first start with a core-libraries container, _then_ a language container, and then packages on top. Having this clarity of composition, I think, is…

I'm not sure what kind of deployment you are envisioning where this makes sense. If you are running a java application, you likely want a bare bones OS + jvm of appropriate version (like the ones being discussed).
Post reply on HN