Re: RFR: 8285890: Fix some @param tags

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 > (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not > included in the API Documentation, are visible in and processed

Integrated: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please > review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be sepa

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5]

ase maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the > doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3]

On Thu, 28 Apr 2022 08:10:38 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/nio/file/Wat

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4]

ase maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the > doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revis

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3]

On Thu, 28 Apr 2022 08:08:37 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/nio/file/Secu

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3]

On Wed, 27 Apr 2022 23:24:57 GMT, Stuart Marks wrote: >> I said "keys maintained", omitting "by this map" to finesse the question of >> if the SimpleEntry class *is* a map, or is used to implement a map, etc. I >> can change it to include "by this map" if the map/entry distinction is okay >>

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3]

ase maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the > doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revis

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2]

On Wed, 27 Apr 2022 10:55:22 GMT, Daniel Fuchs wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains three

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2]

ase maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the > doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

On Wed, 27 Apr 2022 10:54:00 GMT, Daniel Fuchs wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), >> please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated >>

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

On Wed, 27 Apr 2022 01:39:27 GMT, Stuart Marks wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), >> please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated >>

RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. Making

Re: RFR: 8284105: Update security libraries to use sealed classes

On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote: > Please review these changes to update the security libraries to use sealed > classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes > that did not have

Integrated: JDK-8282686: Add constructors taking a cause to SocketException

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote: > Please review this small API enhancement to add the usual constructors taking > a cause to SocketException and then update uses of initiCause on creating > SocketException to instead pass the cause via the constructor. > > Ple

Re: RFR: JDK-8282686: Add constructors taking a cause to SocketException [v3]

.net/browse/JDK-8282688 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve test. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7705/files - new: https://git.openjdk.java.net/jdk/pull/7705/files/978b379d..da

Re: RFR: JDK-8282686: Add constructors taking a cause to SocketException [v2]

.net/browse/JDK-8282688 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Add regression

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7268

RFR: JDK-8282686: Add constructors taking a cause to SocketException

Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Integrated: JDK-8281082: Improve javadoc references to JOSS

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not > done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. This pull request has now bee

Re: RFR: JDK-8281082: Improve javadoc references to JOSS [v2]

> The references to JOSS, the Java Object Serialization Specification, are not > done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit si

RFR: JDK-8281082: Improve javadoc references to JOSS

The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. I'll update copyright years before pushing. - Commit messages: - JDK-8281082: Improve javadoc references to JOSS Changes:

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13]

On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v26]

On Mon, 22 Nov 2021 12:09:30 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java > API" portion of JEP 421 ("Deprecate Finalization for Removal") for code > review. > > This change makes the indicated deprecations, and updates the API

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it at > mass? > > As far as I remember, the first mass-canonicalization of modifiers took place

Integrated: 8275003: Suppress warnings on non-serializable non-transient instance fields in windows mscapi

On Sat, 9 Oct 2021 19:41:51 GMT, Joe Darcy wrote: > Analogous to other recent cleanups like JDK-8274393, suppress warnings for > serialization-related issues in the windows mscapi code. This pull request has now been integrated. Changeset: 926966be Author: Joe Darcy URL:

RFR: 8275003: Suppress warnings on non-serializable non-transient instance fields in windows mscapi

Analogous to other recent cleanups like JDK-8274393, suppress warnings for serialization-related issues in the windows mscapi code. - Commit messages: - Applease jcheck. - 8275003: Suppress warnings on non-serializable non-transient instance fields in windows mscapi Changes:

Re: RFR: 8274835: Remove unnecessary castings in java.base

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to select only casts which are definitely safe to remove. Also didn't > touch primitive types casts. Curious. The JDK build is done with javac

Integrated: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

On Mon, 27 Sep 2021 19:24:39 GMT, Joe Darcy wrote: > Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial > checking are out for review (#5709) and various security libraries would need > some changes to pass under the expanded checks. > > The changes

Re: RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs [v3]

serializable types are not declared with a type statically known to be > serializable. That isn't necessarily a correctness issues, but it does merit > further scrutiny. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exclud

Re: RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs [v2]

serializable types are not declared with a type statically known to be > serializable. That isn't necessarily a correctness issues, but it does merit > further scrutiny. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exclud

Re: RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs [v2]

On Wed, 29 Sep 2021 18:13:14 GMT, Joe Darcy wrote: >> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial >> checking are out for review (#5709) and various security libraries would >> need some changes to pass under the expanded checks. >> >&g

RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs

Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking are out for review (#5709) and various security libraries would need some changes to pass under the expanded checks. The changes are to suppress warnings where non-transient fields in serializable types are not

RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields

This is an initial PR for expanded lint warnings done under two bugs: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type to get feedback

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote: >> 8274075: Fix miscellaneous typos in java.base > > Pavel Rappo has updated the pull request incrementally with one additional > commit since the last revision: > > Tweak wording for Throwable constructor parameters Marked as reviewed by

Re: RFR: 8272626: Avoid C-style array declarations in java.*

On 8/18/2021 6:20 AM, Roger Riggs wrote: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. (Copyrights intentionally not updated due the triviality of most changes) 34

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v6]

On 6/21/2021 2:02 PM, Paul Sandoz wrote: On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang wrote: After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. Yi Yang has updated

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. >

Integrated: 8264148: Update spec for exceptions retrofitted for exception chaining

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining This pull request has now been integrated. Changeset: 815248ab Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/815248ab Stats: 84 lines in

Re: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining

On 3/30/2021 6:29 AM, Roger Riggs wrote: On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: 8264148: Update spec for exceptions retrofitted for exception chaining I agree that the public field in WriteAbortedException could be remediated. But it is also mostly harmless. src

Re: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining

On 3/30/2021 6:43 AM, jmehrens wrote: On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: 8264148: Update spec for exceptions retrofitted for exception chaining src/java.base/share/classes/java/io/WriteAbortedException.java line 86: 84: @Override 85: public Throwable getCause

Re: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks wrote: >> 8264148: Update spec for exceptions retrofitted for exception chaining > > The removal of the obsolescent "As of release 1.4, this exception has been > retrofitted..." is good. Changing the calls from the other exception-getting >

RFR: 8264148: Update spec for exceptions retrofitted for exception chaining

8264148: Update spec for exceptions retrofitted for exception chaining - Commit messages: - Respond to review feedback. - Respond to review feedback. - Merge branch 'master' into 8264148 - Merge branch 'master' into 8264148 - 8264148: Update spec for exceptions retrofitted for

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v37]

On Fri, 26 Mar 2021 12:25:43 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32]

On Thu, 18 Mar 2021 15:08:56 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31]

On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31]

On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Re: RFR: 8263105: security-libs doclint cleanup [v2]

On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the >> security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running >> tier1/tier2 tests. Minor spot checks on generated

Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by

Re: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons wrote: > Please review some minor doc fixes, for issues found by _doccheck_.There > are two kinds of errors that are addressed. > > 1. Incorrect use of ``. In HTML, `` marks the *beginning* of a > paragraph. It is not a terminator, to mark

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21]

On Fri, 19 Feb 2021 12:48:05 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Integrated: 8250564: Remove terminally deprecated constructor in GSSUtil

On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and > deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally depr

RFR: 8250564: Remove terminally deprecated constructor in GSSUtil

Back in JDK 16, two unintended default constructors were identified and deprecated for removal. The time has come to remove them. Please also review the corresponding CSRs: JDK-8258521 Remove terminally deprecated constructor in GSSUtil https://bugs.openjdk.java.net/browse/JDK-8258521

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/814

Re: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs

On 7/24/2020 10:32 AM, Sean Mullan wrote: On 7/24/20 1:18 PM, Joe Darcy wrote: - src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java   37 /**   38  * Do not call.   39  */   40 @Deprecated(since="16", forRemoval=true)   41 public GSSUtil() {

Re: JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs

Hi Sean, On 7/24/2020 4:52 AM, Sean Mullan wrote: Hi Joe, On 7/24/20 1:17 AM, Joe Darcy wrote: Hello, Please review a set of changes to add explicit constructors to replace default (implicit) constructors in various classes in security libs across several modules: JDK-8250246

JDK 16 RFR of JDK-8250246: Address reliance on default constructors in security libs

Hello, Please review a set of changes to add explicit constructors to replace default (implicit) constructors in various classes in security libs across several modules:     JDK-8250246: Address reliance on default constructors in security libs    

JDK 16 RFR of JDK-8247374: Remove default constructors from javax.net.ssl

Hello, Please review the addition of several explicit constructors to abstract classes in javax.net.ssl to remove the use of implicit default constructors; CSR link and patch below:     JDK-8247374: Remove default constructors from javax.net.ssl     CSR:

Re: RFR(S): 8236111 : narrow allowSmartActionArgs disabling

onArgs? I'm assuming this is a jtreg feature but I have not heard of it before. Thanks, Sean Thanks, -- Igor On Jan 2, 2020, at 12:58 PM, Roger Riggs wrote: The core lib changes look ok. Roger On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote: The removal of the existing TEST.properties files loo

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

Hi Chris and Sean, I'll push a fix for JDK-8231262 with a single class-level suppression in X509CertImpl:     @SuppressWarnings("serial") // See writeReplace method in Certificate I've filed         JDK-8232062: Clarify serialization mechanisms of X509CertImpl for the follow-up work.

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

Hi Sean, Getting back to this review... On 9/26/2019 1:55 PM, Sean Mullan wrote: On 9/26/19 4:20 PM, Sean Mullan wrote: Would you prefer I revise the patch where there are multiple SuppressWarnings("serial") on fields to put a single one on the class instead? Yes, but only in the cases

Re: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss

Hi Sean, Amended as requested before pushing; thanks, -Joe On 10/8/2019 2:12 PM, Sean Mullan wrote: I would change "asn1" to "ASN.1" in the comment as that is the more common usage of the acronym, otherwise looks good. Thanks, Sean On 10/8/19 1:36 PM, Joe Darcy wro

Re: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss

PS And a revised webrev acting on comments from the JDK-8231262 to use a single class-level @SuppressWarnings when an alternative serial form is implicitly being used:     http://cr.openjdk.java.net/~darcy/8231368.1/ Thanks, -Joe On 10/8/2019 10:11 AM, Joe Darcy wrote: Hi Sean, Returning

Re: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss

n contrast, the javax.security.auth.kerberos.EncryptionKey class is declared to be Serializable. Therefore, the @SuppressWarnings on the field in the initial patch is needed. If the patch looks good, I'll get this pushed. Thanks, -Joe --Sean On 9/23/19 8:15 PM, Joe Darcy wrote: Hello, Anot

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Hello, At least from a quick reading, either the spec change or the behavior change would seem to merit a CSR. Cheers, -Joe On 10/2/2019 4:26 PM, Ivan Gerasimov wrote: Hi Chris! Thank you very much for review! I agree that it makes sense to update the javadoc for consistency. I don't

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

Hi Sean, On 9/26/2019 12:46 PM, Sean Mullan wrote: On 9/23/19 4:16 PM, Joe Darcy wrote: Hi Sean, On 9/23/2019 12:19 PM, Sean Mullan wrote: Hi Joe, It's a little odd to suppress the warnings in the X509CertImpl class since it is a subclass of java.security.cert.Certificate which implements

JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss

Hello, Another module, another review request as part of making serial warnings more robust:     JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss     http://cr.openjdk.java.net/~darcy/8231368.0/ (Related earlier review

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

Hi Sean, On 9/23/2019 12:19 PM, Sean Mullan wrote: Hi Joe, It's a little odd to suppress the warnings in the X509CertImpl class since it is a subclass of java.security.cert.Certificate which implements the writeReplace method so these fields are not serialized. Also for other classes like

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

On 9/21/2019 4:15 AM, Chris Hegarty wrote: On 19 Sep 2019, at 18:32, Joe Darcy wrote: Hello, Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be helpful to mark fields in security libs classes where the class is serializable, but a non-transient instance field

JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

Hello, Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be helpful to mark fields in security libs classes where the class is serializable, but a non-transient instance field does *not* have a serialiable type. Such classes may have difficulties being serialized at

Re: JDK 14 RFR of JDK-8229999 : Apply java.io.Serial annotations to security types in java.base

is not @Documented so it doesn't appear in the generated javadoc. Thanks, -Joe --Sean On 8/27/19 8:16 PM, Joe Darcy wrote: Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention o

JDK 14 RFR of JDK-8229999 : Apply java.io.Serial annotations to security types in java.base

Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention of this new annotation type is to allow serialization-related fields and methods to be marked as documentation and to allow

Re: RFR - CSR: 8213082: (zipfs) Add support for POSIX file permissions

Hello, On 12/21/2018 8:43 AM, Volker Simonis wrote: Hi Alan, thanks for looking at this issue. I've dived into the ZipFS implementation during the last weeks and together with Christoph we've extended and improved both the implementation the test coverage. As Christoph already emphasized, this

JDK 12 RFR of JDK-8213911: Use example.com in java.net and other examples

Hello, Please review a simple doc-only change to address:     JDK-8213911: Use example.com in java.net and other examples     http://cr.openjdk.java.net/~darcy/8213911.0/ Patch below. Thanks, -Joe --- old/src/java.base/share/classes/java/net/HostPortrange.java 2018-11-26

Re: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike

Changes look fine; thanks, -Joe On 10/1/2018 4:43 PM, Lance Andersen wrote: The changes look reasonable Ivan On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov wrote: Hello! A handful of a few similar typos across core-libs/security-libs areas. BUGURL:

Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings -- now RFR for 8209304: Deprecate serialVersionUID fields in interfaces

Hi Alan, On 8/6/2018 11:12 PM, Alan Bateman wrote: On 06/08/2018 20:11, joe darcy wrote: Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to

Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

Hi Sergey, On 8/6/2018 3:39 PM, Sergey Bylokhov wrote: Hi, Joe. On 06/08/2018 14:30, joe darcy wrote: Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Can you please cla

Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

would probably have used "ineffective" instead of "ineffectual". (Googling "define ineffective" and "define ineffectual" shows an interesting graph of the use of the term with ineffective growing and ineffectual dropping in use. Look under the more tag) R

JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the

Re: JDK 11 RFR of JDK-8196414: Update ProviderVersionCheck.java to pass on updated JDK versions

Hi Sean, On 1/30/2018 10:03 AM, Sean Mullan wrote: Does Runtime.version().feature() return the same value as the "java.specification.version" property? (see sun.security.util.SecurityConstants.PROVIDER_VER). That is the value that the JDK security providers use as their version. If not,

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

I understand the interest in having test pass reliably, but I don't think giving the test very large timeouts is the preferred way of accomplishing that. For all configurations, the test can now run for up to 20 minutes, up from 4 minutes. We want to run the entire test suite, thousands of

Re: RFR: 8179370: Replace use of , and tags in java.base

Looks better; thanks Jon, -Joe On 4/26/2017 6:49 PM, Jonathan Gibbons wrote: Updated webrev to address Joe's suggestion to try harder to use {@code} as a substitute for . http://cr.openjdk.java.net/~jjg/8179370/webrev.01 The modified sed script has a new first line: s|\([^&<>]*\)|{@code

Re: RFR of 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool

question: -@SuppressWarnings("deprecation") +@SuppressWarnings({"deprecation", + "removal"}) // PolicyTool Why did you split the line to 2? Thanks Max On 03/28/2017 09:09 AM, joe darcy wrote: Hello, The jdk.security and jdk.policytool modules use va

RFR of 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool

Hello, The jdk.security and jdk.policytool modules use various APIs that are deprecated for removal. Until the types in question are actually removed, the lint removal warnings should be suppressed in support of having a warnings-free build. Please review the webrev:

Re: 9 RFR of JDK-8176337: Mark several tests as intermittently failing

Looks fine Hamlin; thanks, -Joe On 3/7/2017 7:36 PM, Hamlin Li wrote: Would you please review below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176337 webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ These tests are failing intermittently, they should be marked

JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10

Hello, After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including: java/lang/module/MultiReleaseJarTest.java java/security/Provider/ProviderVersionCheck.java sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java These tests need to

JDK 9 RFR of JDK-8171062: Problem list ServerIdentityTest.java on window

Hello, Until JDK-8171061 is fixed, the test sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java should be problem listed on windows. Patch below. Thanks, -Joe diff -r b9cdffb87bea test/ProblemList.txt --- a/test/ProblemList.txtWed Dec 07 10:55:13 2016 -0500 +++

Re: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission

this permission target belongs in RuntimePermission since it is specific to Oracle's Java Plugin. I would be in favor of removing it and only documenting it in the deployment guides. --Sean On 09/08/2016 02:17 PM, Lance Andersen wrote: all good Joe On Sep 8, 2016, at 2:16 PM, joe darcy

JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission

Hello, Please review the patch below to address JDK-8039854: Broken link in java.lang.RuntimePermission Two broken links are replaced by a live link to the deployment guide. Thanks, -Joe --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 16:16:44 2016 +0100

JDK 9 RFR mark java/security/SignedObject/Chain.java as failing intermittently

Hello, The test java/security/SignedObject/Chain.java has been seen to fail intermittently (JDK-8136842). I'd like to mark the test accordingly; please review the test below which does this. Thanks, -Joe --- a/test/java/security/SignedObject/Chain.javaThu Jul 07 10:16:47 2016 -0700

JDK 9 RFR of JDK-8159502: Mark ShortRSAKey512.java as intermittently failing

The test javax/net/ssl/TLSv12/ShortRSAKey512.java has been seen to intermittently fail (JDK-8159501). The test should be marked accordingly. Please review the patch below which does this. Thanks, -Joe diff -r d6a1ad87842f test/javax/net/ssl/TLSv12/ShortRSAKey512.java ---

JDK 9 RFR of JDK-8156897: Problem list ShortRSAKey1024.sh on windows

Hello, The test sun/security/mscapi/ShortRSAKey1024.sh has been seen to fail with some frequency on windows. Until JDK-8153948 is addressed, the test should be problem listed. Please review the patch below which does this. Thanks, -Joe diff -r b14b89e259ac test/ProblemList.txt ---

Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

he checked exception language contract Date: Thu, 21 Apr 2016 09:25:27 -0700 From: joe darcy <joe.da...@oracle.com> Organization: Oracle Corporation To: core-libs-dev <core-libs-...@openjdk.java.net> Hello, After a generally positive reception, please review the webrev to imp

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

On 3/30/2016 5:34 PM, Mandy Chung wrote: On Mar 30, 2016, at 4:48 PM, Joseph D. Darcy wrote: Hi Mandy, Hopefully the third time will be the charm for this changeset after your correction to the commented-out test: http://cr.openjdk.java.net/~darcy/8151763.2 I

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Hi Mandy, On 3/28/2016 8:48 PM, Mandy Chung wrote: On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: Hello, New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. http://cr.openjdk.java.net/~darcy/8151763.1 #

JDK 9 RFR of JDK-8151835: Mark SmallPrimeExponentP.java as intermittently failing

Hello, The test sun/security/mscapi/SmallPrimeExponentP.java has been seen to timeout intermittently, bug JDK-8151834. The sources of the test should be marked accordingly; please review the corresponding patch below. Thanks, -Joe --- a/test/sun/security/mscapi/SmallPrimeExponentP.java

JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the

JDK 9 RFR of JDK-8151228: Mark TestDSAGenParameterSpec.java as intermittently failing

Hello, The test sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java has been observed to intermittently fail (JDK-8137255). Until that problem is resolved, the test should be marked accordingly. Please review the patch below which does that marking. Thanks, -Joe ---

JDK 9 RFR of JDK-8151225: Mark SpecTest.java as intermittently failing

Hello, The test sun/security/rsa/SpecTest.java has been observed to fail intermittently with a timeout (JDK-8137231). The observed timeouts have been for the largest key size. Until that issue is resolved, the test should be marked as failing intermittently. Please review the patch below

  1   2   3   4   >