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.)
