Manifest resolution order in multi-release jar

[Luke Hutchison]

JEP 238 says "JAR metadata, such as that found in the MANIFEST.MF file and
the META-INF/services directory, need not be versioned." However, if a
manifest file is present in the base layer *and* a version layer, what are
the correct semantics? e.g.

META-INF/MANIFEST.MF :

Multi-Release: true
X: 1
Y: 2

META-INF/versions/9/META-INF/MANIFEST.MF :

X: 3

I am guessing that META-INF/MANIFEST.MF is only read to check for
Multi-Release:
true , and if found, META-INF/versions/* is checked for versioned
META-INF/MANIFEST.MF entries, using the normal multi-release resolution
order. If one is found, that is read as the manifest file, in place of the
base layer manifest file that was already opened (and the rest of
META-INF/MANIFEST.MF , i.e. X: 1 ; Y: 2 is ignored). We end up reading only X:
3 as the manifest attribute values.

Is that correct? (If so, it's a bit of a "Shroedinger's cat" situation
here, since META-INF/versions/9/META-INF/MANIFEST.MF does not contain
Multi-Release:
true , but I assume this manifest entry is ignored or not needed once it is
established that this is a multi-release jar...)

Or should a versioned manifest file be "merged on top of" the base manifest
file, so we end up with Multi-Release: true ; X: 3 ; Y: 2 ?

(I am basing this question on the text of the JEP rather than any current
implementation, since as far as I can see, the JEP does not specify the
behavior, raising the possibility that this may change in the future.)

[Alan Bateman]

Post by Luke Hutchison
JEP 238 says "JAR metadata, such as that found in the MANIFEST.MF file
and the META-INF/services directory, need not be versioned." However,
if a manifest file is present in the base layer /and/ a version layer,
what are the correct semantics? e.g.
Multi-Release: true
X: 1
Y: 2
X: 3

The intention is that the META-INF directory cannot be versioned. I
agree the JEP and the JarFile API spec isn't very clear on this point.
The implementation does handle it correctly, meaning getJarEntry will
locate the resource in top-level META-INF directory, not the versioned
section. It will also not find resources that are only present in the
META-INF directory of versioned sections.

-Alan