RFR: 8215788: Clarify JarInputStream Manifest access [v4]

Alan Bateman alanb at openjdk.org
Fri Sep 16 13:34:48 UTC 2022


On Wed, 14 Sep 2022 16:43:43 GMT, Lance Andersen <lancea at 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



More information about the security-dev mailing list