Add jdk info as metadata to container

[loosebazooka]

Similar to GoogleContainerTools/distroless#276

Would be great for tooling if we could get the following metadata directly from container configuration:

• jdk.vendor: the vendor of the JDK.
• jdk.version: the version of the JDK, e.g., 1.8.0_131 or 9.0.1 that can be obtained by java -version.

Labeling would potentially have to deal with jre only builds as well.

[tianon]

I'm not completely against adding LABEL metadata to these images, but the proposed labels don't follow the recommended "reverse DNS" format (https://docs.docker.com/config/labels-custom-metadata/#key-format-recommendations).

Also, I don't really understand what value this would provide over scraping this directly from java -version? (which will be a lot less likely to be outdated / have accidental omissions)

[loosebazooka]

Yeah, my label choice was arbitrary. I just wanted to get the point across.

This is more useful for tools that want information about the container without actually executing them. For example:

• An execution environment that wants to inject parameters when starting a container (a java kubernetes controller). Different java versions have different available parameters / config styles and providing that meta data to the controller can help it do its job easier.
• A build tools making decisions based on the base image, if the base image is java8 then don't allow java11 classes (or something)

[lifeModder19135]

I'm not completely against adding LABEL metadata to these images, but the proposed labels don't follow the recommended "reverse DNS" format (https://docs.docker.com/config/labels-custom-metadata/#key-format-recommendations).

Also, I don't really understand what value this would provide over scraping this directly from java -version? (which will be a lot less likely to be outdated / have accidental omissions)

As for the first point, the reference documentation only says to prefix your labels with your vendor specific reverse DNS "signature." So long as that single rule is followed, and, more importantly, assuming the powers-that-be had the foresight to implement some sort of 'unique-signature-enforcement-policy' (whatever that may look like), anyone can add anything to their configurations without any fear of repercussions. In fact, adding a label to the OpenJDK config that holds only the middle name of the lead engineer's favorite NBA power forward from the early 90s is perfectly valid as long as the key is something like:

    com.openjdk-domain-name.middle-name-of-lead-engineer's-favorite-NBA-power-forward-from-the-early-90s

with that said, the first suggestion from @loosebazooka doesn't really make sense anyway, because the vendor name is not only in the config already, it is by definition, in the key of every label in every config file.

As for the second part of your comment, one of the main points of maintaining config files such as these is to provide a single point of access for all configurable values. As you know, the possible use cases for accessing these is infinite as far as we are concerned, so there is no point in trying to lay them out based on how it will be used. For example, regarding a java version label, I could think of valid reasons to stub out the value of this property, at least temporarily. Adding it as a label will make actions such as this a lot more streamlined.

Since, in most cases, the valuewould be set-and-forget at the actual value of the java version, I would set it up so that it initializes via 'java-version', and from there, it is up to the user to change it or leave it be.

BTW, sorry for the rambling over-explanation. I got a bit carried away.... ...It's very late here.

[tianon]

Unfortunately, this isn't something we want to implement/maintain, but thank you for the suggestion!