On Fri, 16 Sep 2022 13:06:28 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address latest input regarding wording
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 44:
>
>> 42: * The {@link #getManifest} method will return the {@code Manifest} when
>> it is
>> 43: * the first entry in the stream, or {@code META-INF/} is the first
>> entry and
>> 44: * the {@code Manifest} is the second entry within the stream.
>
> "within the stream" should probably be "in the stream" to be consistent the
> first part of the sentence.
Updated as you suggested
> 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.
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 78:
>
>> 76: * the signers.
>> 77: * <p>
>> 78: * <b>Note:</b> If a {@code JarEntry} is modified after the JAR file is
>> signed,
>
> Can this be an apiNote?
Sure Updated as suggested
-------------
PR: https://git.openjdk.org/jdk/pull/10045
