On Wed, 14 Sep 2022 16:43:43 GMT, Lance Andersen <lan...@openjdk.org> wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this update, we are finally documenting
>> behavior that dates back to when this class was added to JDK 1.2
>>
>>
>> Best,
>> Lance
>
> 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.
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.
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?
-------------
PR: https://git.openjdk.org/jdk/pull/10045
