RFR: 8215788: Clarify JarInputStream Manifest access [v4]

[Alan Bateman]

On Fri, 16 Sep 2022 16:15:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarInputStream.java line 51:
>> 
>>> 49:  * If {@code META-INF/} is the first entry in the input stream it will be
>>> 50:  * also not be returned by {@link #getNextEntry()} and
>>> 51:  * {@link #getNextJarEntry()}.
>> 
>> JAR files will almost always have the manifest as the first or second entry. It's very hazardous to have getNextEntry/getNextJarEntry work differently when the manifest is present but not at the start. This makes it really hard to specify too. I wonder what the impact would be of changing the implementation so that getNextEntry/getNextJarEntry consistently skip the manifest rather than only when it's at the start. I can't think of anything right now that could dependent on the current behavior where it might or might be returned.
>
> I tend to agree but am reluctant to change 20+ year behavior via this PR as we don't know what we don't know.

Okay, in which case what would you think about just saying that the getNextEntry/getNextJarEntry method do not return the Manifest when it's at the start of the stream, and it's unspecified whether they return the Manifest when it located later in the stream. I think this would give us wriggle room to change it in the future.

-------------

PR: https://git.openjdk.org/jdk/pull/10045