On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the
> increase in memory footprint of an application that uses signed JAR files,
> signed with `SHA-384` digest algorithm? This addresses
> https://bugs.openjdk.org/browse/
On Fri, 21 Mar 2025 19:23:59 GMT, Hai-May Chao wrote:
>> The jarsigner -verify command currently performs verification by reading
>> from JarFile to navigate the central directory (CEN) headers. It is now
>> enhanced to include cross-validation of entries between JarFile (CEN-based)
>> and Jar
On Mon, 10 Mar 2025 21:11:15 GMT, Kevin Driver wrote:
>> test/jdk/sun/security/tools/jarsigner/MultiManifest.jar line 1:
>>
>>> 1: PKO�rY
>>> META-INF/��PKPKO�rYMETA-INF/MANIFEST.MF�M��LK-.�
>>
>> We usually do not include a binary file in the code repository. Can you
>>
On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote:
> This change adds an API note to these methods recommending that the caller
> should perform further validation steps on the code signers that signed the
> JAR file, such as validating the code signer's certificate chain, and
> determining
On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Mon, 2 Dec 2024 20:12:39 GMT, Roger Riggs wrote:
> Remove sun/security/action/GetPropertyAction.java and all uses.
>
> Dependent on PR#22418
Changes Look Good Roger
-
Marked as reviewed by lancea (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/22497#pullrequestreview-2
On Mon, 18 Nov 2024 21:56:12 GMT, Brian Burkhalter wrote:
>> Expunge the use of the `SecurityManager`, `AccessController`, and the like
>> from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 834
On Thu, 14 Nov 2024 20:25:35 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which cleans up security manager related code in
>> `java.util.zip` and `java.util.jar`:
>>
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead
>> of `GetPropertyAction::privilegedGetProp
On Thu, 14 Nov 2024 19:59:55 GMT, Sean Mullan wrote:
>> Yes, they are 96 and 98 chars long, which means I sympathise with both views
>> :)
>>
>> Unless hearing back from @seanjmullan I'll go with Roger's suggestion of one
>> line here.
>
> I think both are in the 90-100 range. Line length is a
On Thu, 14 Nov 2024 19:45:27 GMT, Eirik Bjørsnøs wrote:
>> src/java.base/share/classes/java/util/jar/JarFile.java line 182:
>>
>>> 180: }
>>> 181: RUNTIME_VERSION =
>>> Runtime.Version.parse(Integer.toString(runtimeVersion));
>>> 182: String enableMultiRelease =
>>> Sys
On Thu, 14 Nov 2024 13:21:33 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which cleans up security manager related code in
>> `java.util.zip` and `java.util.jar`:
>>
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead
>> of `GetPropertyAction::privilegedGetProp
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 20 Sep 2024 12:30:00 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial typo fix in `JarFile` class'
> javadoc?
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/21108#pullrequestreview-2318248221
On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentati
On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote:
> Candidates for this refactoring were found programmatically; the program to
> find candidates is in a comment on the bug.
I went through the changes and they look fine.
-
Marked as reviewed by lancea (Reviewer).
PR Review: http
On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalFileAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>>
On Fri, 3 May 2024 09:27:28 GMT, Sean Coffey wrote:
> Incorporate man page changes related to JDK-8281658 and related issues
> (including JDK-8311653)
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19078#pullrequestreview-2038328561
On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>> the
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
> [JDK-8066619](https://
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote:
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package
On Wed, 28 Feb 2024 14:03:58 GMT, Jaikiran Pai wrote:
> GitHub doesn't allow me to comment on unchanged lines in the PR, but while
> reviewing this I noticed 2 things:
>
> * It looks like http://www.pkware.com/documents/casestudies/APPNOTE.TXT is
> now auto redirecting to
> https://pkware.cac
On Wed, 28 Feb 2024 13:58:01 GMT, Jaikiran Pai wrote:
> Hello Lance, this doc-only change looks good to me.
>
> These changes are merely changing the case of `zip` and aren't changing any
> specification of the APIs and that looks fine to me.
>
> I had imagined that we would be changing only t
On Wed, 28 Feb 2024 14:13:57 GMT, Guoxiong Li wrote:
> I search the package `java.util.zip` and find several `zip64` in the file
> [ZipConstants64.java](https://github.com/openjdk/jdk/blob/baa67f1130947c7204fc12018d25bfb48528784c/src/java.base/share/classes/java/util/zip/ZipConstants64.java#L51)
On Tue, 27 Feb 2024 15:08:11 GMT, Eirik Bjørsnøs wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address initial feedback for JDK-8326687
>
> src/java.base/share/classes/java/util
el location of the PKWARE
> APPNOTE.TXT has PKWare recently changed the direct path the the latest
> version of the spec.
>
> It is also worth noting that error messages were not updated as part of the
> PR and will be updated separately to keep the javadoc changes separate
Lan
On Tue, 27 Feb 2024 16:12:03 GMT, Lance Andersen wrote:
>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
>> module summary so that it is consistent with the use of "ZIP".
>>
>> In addition,
>> open/src/java.base/share/cla
This PR updates the javadoc and comments within java.util.zip/jar and zipfs
module summary so that it is consistent with the use of "ZIP".
In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
has been updated to point to the higher level location of the PKWARE
APPNOTE.T
On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>> th
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Tue, 6 Feb 2024 10:31:06 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>> th
On Fri, 2 Feb 2024 20:19:51 GMT, Eirik Bjørsnøs wrote:
> > I think the change is OK, any reason to not make it
> > `externalFileAttributes`?
>
> None other than length / verbosity. But since this refers to the _attributes
> of the external file_, dropping any name element also loses some seman
On Tue, 30 Jan 2024 16:17:13 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>> the
On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bjorsnos wrote:
> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
> to `ZipEntry.externalAttributes`.
>
> This field was introduced in
> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
> the name `
On Thu, 13 Jul 2023 18:07:54 GMT, Justin Lu wrote:
>> Please review this PR which addresses `KeytoolReaderP12Test.java` failing
>> for non-English locale users.
>>
>> This test checks output from keytool, but fails on finding the value 'alias
>> name' for non-English locale users. This is beca
On Fri, 7 Jul 2023 18:58:02 GMT, Justin Lu wrote:
> Please review this PR which addresses `KeytoolReaderP12Test.java` failing for
> non-English locale users.
>
> This test checks output from keytool, but fails on finding the value 'alias
> name' for non-English locale users. This is because 'a
On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote:
> Updated the version to 22-ea and year to 2024.
>
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage
> contains a special character
> - [
On Fri, 12 May 2023 17:52:29 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/Console.java line 124:
>>
>>> 122: * if (con != null) {
>>> 123: * Scanner sc = new Scanner(con.reader());
>>> 124: * ...
>>
>> I'm not sure how you fe
On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos wrote:
>> This PR removes the JAR index feature from the runtime:
>>
>> - `URLClassPath` is updated to remove the `enableJarIndex` system property
>> and any code which would be called when this property was `true`
>> - The `JarIndex` implementat
On Fri, 7 Apr 2023 07:47:49 GMT, Eirik Bjorsnos wrote:
>> This PR removes the JAR index feature from the runtime:
>>
>> - `URLClassPath` is updated to remove the `enableJarIndex` system property
>> and any code which would be called when this property was `true`
>> - The `JarIndex` implementat
On Wed, 5 Apr 2023 07:05:11 GMT, Eirik Bjorsnos wrote:
> > The new test that was planned for testing `JarFile` and `JarInputStream`
> > when dealing with a jar containing a `META-INF/INDEX.LIST`, is that
> > something that you want to be done as a separate PR/task? It's fine with me
> > if you
On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs wrote:
> With the addition of `jdk.internal.util.OperatingSystem` references to the
> system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
> - java.prefs,
> - java.security.jgss,
> - java.smartcardio,
> - jdk.charsets
On Tue, 4 Apr 2023 18:37:34 GMT, Alan Bateman wrote:
> > I have drafted CSR https://bugs.openjdk.org/browse/JDK-8305597, but I'm not
> > sure what to put in the _Specification_ section.
> > What is the specification change in this PR? The removal of the system
> > property? The adding of the wa
On Thu, 30 Mar 2023 14:21:29 GMT, Eirik Bjorsnos wrote:
>> This PR removes the JAR index feature from the runtime:
>>
>> - `URLClassPath` is updated to remove the `enableJarIndex` system property
>> and any code which would be called when this property was `true`
>> - The `JarIndex` implementa
On Fri, 31 Mar 2023 10:33:50 GMT, Lance Andersen wrote:
> Hi Jon,
>
> This looks fine. I was wondering if we should do the same for java.util.zip
> and the PKWare Zip Spec or where java.sql references the JDBC Spec?
Well, I must need coffee this morning as obviously JDBC is in
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote:
>> Please review a change to add `@spec` tags (and remove some equivalent
>> `@see` tags) to the main "core-libs" packages in `java.base` module.
>>
>> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and
>> base
On Sat, 25 Mar 2023 09:35:56 GMT, Alan Bateman wrote:
> > I see that Alan suggested that we take up the `jar -i` deprecation in a
> > separate PR. I think that simplifies the work in this PR.
>
> Yes, there are options for `jar -i` that include "leave it as is", have the
> option create the in
On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote:
>> Please review this superficial documentation cleanup that was triggered by
>> unrelated analysis of doc comments in JDK API.
>>
>> The only effect that this multi-area PR has on the JDK API Documentation
>> (i.e. the observable effect on t
On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos wrote:
> The `-altsigner` and `-altsignerpath` options in JarSigner with the
> underlying `ContentSigner` mechanism were deprected in Java 9, for removal in
> Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535),
> [JDK-824226
On Wed, 1 Mar 2023 07:52:58 GMT, Eirik Bjorsnos wrote:
> Suggested CSR:
>
> ### Compatibility Kind:
> source, binary, behavioral
>
> ### Compatibility Risk
> minimal
>
> ### Compatibility Risk Description
> The APIs were deprecated in JDK 9 with no known existing use. The probability
> that t
On Tue, 28 Feb 2023 19:09:00 GMT, Eirik Bjorsnos wrote:
> The `-altsigner` and `-altsignerpath` options in JarSigner with the
> underlying `ContentSigner` mechanism were deprected in Java 9, for removal in
> Java 15. See [JDK-8076535](https://bugs.openjdk.org/browse/JDK-8076535),
> [JDK-824226
On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Wed, 15 Feb 2023 09:55:04 GMT, Eirik Bjorsnos wrote:
> The habit of opening resources in a TwR is hard to break, but I guess it's ok
> for a test like this. I have inlined the method and removed the TwR.
Agree, thanks for addressing the suggestion as it makes the test cleaner given
expects/
On Tue, 14 Feb 2023 11:49:23 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> Strin
On Tue, 14 Feb 2023 08:47:15 GMT, Eirik Bjorsnos wrote:
>> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:
>>
>>> 88: expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
>>> 89: public void shouldRejectInvalidName() throws IOException {
>>>
On Thu, 9 Feb 2023 12:07:04 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
diff
Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290
PR: https://git.openjdk.org/jdk/pull/12290
[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]
Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>
On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote:
> Please review this simple update to the manpage to set the version to 21-ea.
>
> This change also corrects a typo in javac.1 that was manually introduced by
> JDK-8300591
>
> Thanks.
Marked as reviewed by lancea (Reviewer).
On Fri, 20 Jan 2023 12:19:50 GMT, Claes Redestad wrote:
>> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates
>> on a `byte[]` subrange. It can profitably use the recently introduced
>> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
>> translates to
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
> translates to a s
On Wed, 14 Dec 2022 06:35:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which fixes some typos in the files
>> under test/jdk/sun/security/tools/jarsigner/?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the last revision
On Thu, 24 Nov 2022 08:19:17 GMT, Per Minborg wrote:
> This PR proposes adding `@Serial` annotations to certain fields participating
> in serialisation.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/11347
On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which fixes the typos in the test
>> packages? @mernst submitted this as a separate PR
>> https://github.com/openjdk/jdk/pull/10029 but given the number of areas and
>> files that other PR touches
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen 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 w
On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote:
>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains six commits:
>
> - Reinstate t
On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman wrote:
>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> src/java.base/share/native/libzip/zlib/zlib.h line 756:
>
>> 754:If this is done, the old level and strategy will be applied to the
>> data
>> 755:com
On Fri, 23 Sep 2022 17:38:47 GMT, Sean Mullan wrote:
> As a side comment, I notice that `JarInputStream` capitalizes "JAR", whereas
> `JarFile` does not ("jar"). We should really be consistent in our javadocs. I
> think "JAR" is more correct, mainly because that is what the Jar File
> specific
On Wed, 21 Sep 2022 09:23:31 GMT, Alan Bateman wrote:
> > Assuming we are set with the other changes, did you want to add the
> > following paragraph (or similar) at line 58 to make it clear that if the
> > Manifest is not found, then the JarEntry attributes will not be available:
>
> This is
On Tue, 20 Sep 2022 17:47:03 GMT, Lance Andersen 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
On Tue, 20 Sep 2022 17:53:27 GMT, Sean Mullan wrote:
> Now that this API has a section about signed JARs, I think it is very
> important to include the following sentences which are copied from `JarFile`:
>
> "Please note that the verification process does not include validating the
> signer's
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:
Added the verification note from JarFile
-
Changes:
- all: https://git.op
On Tue, 20 Sep 2022 17:37:50 GMT, Alan Bateman wrote:
>>> > OK, will make another pass at this today
>>>
>>> I looked at the latest draft
>>> ([2bafc00](https://github.com/openjdk/jdk/commit/2bafc00cc462b7af3f724371ac1bef5fd99c989c)).
>>> I think it would help if the section "Verifying a JarIn
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:
More wordsmithing to the signed jar section
-
Changes:
- all: https://git.op
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 comments regarding Verifying a JarInputStreams
-
Changes:
- all: ht
On Mon, 19 Sep 2022 20:30:48 GMT, Weijun Wang wrote:
> Does this mean that the "Verifying a JarInputStream" should also avoid
> mentioning "getManifest method returns the manifest"? I understand precisely
> it should be "getManifest method is able to return the manifest if you call
> it".
See
On Tue, 20 Sep 2022 06:56:49 GMT, Alan Bateman wrote:
>>> I realise you've had a few iterations with Max on this section but I'm
>>> concerned that the text is telling the reader that they should use the
>>> 2-arg constructor to verify the signatures when a JAR is signed. The
>>> default is to
On Mon, 19 Sep 2022 19:26:53 GMT, Sean Mullan wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor clarification for verifying an JarInputStream
>
> src/java.base/share/classes/jav
On Mon, 19 Sep 2022 20:04:18 GMT, Lance Andersen 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
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 Sean's input
-
Changes:
- all: https://git.openjdk.org/
On Mon, 19 Sep 2022 06:34:00 GMT, Alan Bateman wrote:
> > I can remove, but I am not sure I agree we need to describe main vs
> > attribute here given we are pointing to the Jar spec and if there is any
> > discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess
> > the clar
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:
Minor clarification for verifying an JarInputStream
-
Changes:
- all: https://
On Mon, 19 Sep 2022 06:45:13 GMT, Alan Bateman wrote:
> I realise you've had a few iterations with Max on this section but I'm
> concerned that the text is telling the reader that they should use the 2-arg
> constructor to verify the signatures when a JAR is signed. The default is to
> verify
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:
Updated to address latest feedback
-
Changes:
- all: https://git.openjdk.or
On Sun, 18 Sep 2022 19:49:51 GMT, Alan Bateman wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Incorporated latest round of input
>
> src/java.base/share/classes/java/util/j
On Sat, 17 Sep 2022 08:05:37 GMT, Alan Bateman wrote:
> It's a bit better but I think we can make it clearer and also link the JAR
> Manifest section of the JAR file spec. Can you try this:
>
> ```
> * The {@link #getManifest() getManifest} method is used to read the
> * JAR Manifest
> * fr
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:
Incorporated latest round of input
-
Changes:
- all: https://git.openjdk.or
On Fri, 16 Sep 2022 18:01:40 GMT, Alan Bateman wrote:
> 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 l
On Fri, 16 Sep 2022 13:06:28 GMT, Alan Bateman 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/j
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 additional javadoc comments
-
Changes:
- all: https://git.openjdk.or
On Wed, 14 Sep 2022 15:53:41 GMT, Weijun Wang wrote:
> I have no more comment.
Thank you Max for your time and input
-
PR: https://git.openjdk.org/jdk/pull/10045
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
-
Changes:
- all: https://git.openjdk.or
On Wed, 14 Sep 2022 12:53:12 GMT, Alan Bateman wrote:
> I think you can insert a comma after "when it is the first entry in the
> stream"? I think that would make it a bit clearer that there are two cases.
Done
>
> Also I'm wondering if the paragraph should be split into two, meaning "When
>
On Wed, 14 Sep 2022 02:22:17 GMT, Weijun Wang wrote:
> Only tiny comments for the last paragraph.
Thank you Max, I addressed the above
>
> That said, I have some questions on the other parts of this file:
>
> 1. In `getNextEntry`, the method spec says "If verification has been
> enabled,
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 a couple of typos in Note
-
Changes:
- all: https://git.openjdk.or
On Wed, 14 Sep 2022 00:39:37 GMT, Weijun Wang wrote:
> On lines 36 and 37, there are two "Manifest". The first uses `linkplain` so
> it's using normal font style, the 2nd uses `code` so it's fixed-width. I
> would like them to be the same. In fact, I would not use `linkplain` at all.
> I only
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:
changed linkplain to link and updated note wording
-
Changes:
- all: https://
On Fri, 26 Aug 2022 15:48:55 GMT, Lance Andersen 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 w
On Tue, 13 Sep 2022 20:39:31 GMT, Weijun Wang 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,
On Fri, 2 Sep 2022 14:50:32 GMT, Alan Bateman wrote:
>> I could do tweak further to say:
>>
>> _`getManifest()` will return the Manifest if it is the first entry or
>> META-INF/ is the first entry and the Manifest is the second entry within the
>> Jar file. When the Manifest is returned by `
1 - 100 of 109 matches
Mail list logo
