Re: RFR: 8284209: Replace remaining usages of 'a the' in source code
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > It's the last issue in the series, and it still touches different areas of > the code. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8771
Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8768
Re: RFR: JDK-8286348: incorrect use of `@serial`
On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc > comments for methods such as `readObject` and `readResolve`. The tag has no > effect in this position other than to trigger warnings from the standard > doclet when running javadoc. > > There is no change to the generated documentation as a result off this > change. In particular, there is no change to the API docs for any of the > modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there > is one outlier, in `java.security.Provider`. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8586
Re: RFR: 8284893: Fix typos in java.base
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a > local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") > in the source code, but they were not local and I dared not change them. > Someone braver than me might take a stab at it, perhaps.. Looks good. I usually like GitHub's colorful diffs, but this is one of those rare cases where looking at the single webrev-generated diff file is so much easier. About the only thing that could improve it would be to reduce the context (i.e. "diff -C"). - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8250
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors > (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are > simple replacements to Locale constructors with `Locale.of()` or Locale > constants, such as `Locale.US`. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283426: Fix 'exeption' typo
On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated type `exeption` Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7879
Re: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5]
On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors >> taking a cause to javax.net.ssl exceptions. The use of initCause in the >> JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > more test case udpate Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7722
Re: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5]
On Fri, 18 Mar 2022 21:00:40 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> more test case udpate > > test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 2: > >> 1: /* >> 2: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights >> reserved. > > I am unsure about the third-party copyrights on these files. They are > probably ok, but you should get approval by someone more familiar. > > Secondly, in the Oracle environment, we generally use a trailing , comma > after the date. e.g. > > `Copyright (C) 2022, ` The location of the copyright is fine. No need to enforce Oracle date formatting. - PR: https://git.openjdk.java.net/jdk/pull/7722
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 Nice tidy of the code. Is there anything that can be done to prevent re-introduction of this trivial problem? Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace? - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268
Re: RFR: 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. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7315
Re: RFR: 8279796: Fix typo: Constucts -> Constructs
On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang wrote: > Two edits. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7147
Re: RFR: 8274333: Redundant null comparison after Pattern.split
On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote: > In couple of classes, result part of arrays of Pattern.split is compared with > `null`. Pattern.split (and hence String.split) never returns `null` in array > elements. Such comparisons are redundant. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5708
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 > in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 > files. Since then modifiers have become a bit lose, and it makes sense to > re-bless (using the JDK-8136583 terminology) them. > > This change was produced by running the below command followed by updating > the copyright years on the affected files where necessary: > > $ sh ./bin/blessed-modifier-order.sh src/java.base > > The resulting change is much smaller than that of 2015: 39 lines spanning 21 > files. > > [^1]: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html > (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-79465) > [^2]: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6213
Re: RFR: 8274075: Fix miscellaneous typos in java.base [v4]
On Wed, 22 Sep 2021 15:38:33 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: > > Add missing "the" > > (Spotted by Brian Burkhalter.) Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5610
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 iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5610
Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read and it's less > error-prone. > It doesn't have any performance impact: java compiler generates similar code > when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5328
Re: RFR: 8267587: Update java.util to use enhanced switch [v6]
On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using >> IntelliJ IDEA refactoring. Some manual adjustments are also performed, >> including indentations, moving comments, extracting common cast out of >> switch expression branches, etc. >> >> I also noticed that there are some switches having one branch only in >> JapaneseImperialCalendar.java. Probably it would be better to replace them >> with `if` statement? > > Tagir F. Valeev has updated the pull request incrementally with two > additional commits since the last revision: > > - JapaneseImperialCalendar: use switch expressions > - Use yield in java.util.Calendar.Builder.build Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4161
Re: RFR: 8263892: More modifier order fixes in java.base
On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt wrote: > Additional changes found in `java.base` of `final private` -> `private > final`. Filed with existing bug because it's the same module; can change to a > different bug number if required. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3094
Re: RFR: 8252833: Correct "no comment" warnings from javadoc in java.smartcardio module
On Thu, 11 Mar 2021 01:13:12 GMT, Bradford Wetmore wrote: > Disable the "missing" target for java.smartcardio from doclint. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2930
Re: RFR: 8263105: security-libs doclint cleanup [v3]
On Tue, 9 Mar 2021 22:19:28 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 files. > > Bradford Wetmore has updated the pull request incrementally with one > additional commit since the last revision: > > More Codereview Comments Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2856
Re: RFR: 8263105: security-libs doclint cleanup
On Sat, 6 Mar 2021 07:31:09 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 files.
I'm happy to see a reduction in the number of warnings.
I suspect there are a few places where Object{In,Out}putStream is fully
qualified when it's not strictly necessary; however, since this is in
pre-existing code, I don't think this needs to be changed now.
src/java.base/share/classes/java/security/KeyPair.java line 53:
> 51:
> 52: /**
> 53: *
Extra line?
-
Marked as reviewed by iris (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2856
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 iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
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. Nice clean-up. - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814
RE: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions
Hi, Sean. These changes look good. Thanks, iris -Original Message- From: Sean Mullan Sent: Wednesday, January 2, 2019 12:43 PM To: security Dev OpenJDK ; IRIS,CLARK Subject: RFR (12): 8215318: Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions Please review this change to the Java Security Standard Algorithm Names specification [1] to clarify that standard names that are defined in later versions of SE are also supported in prior versions, as long as the applicable Security APIs are also supported. Please see the CSR for the motivation and exact wording changes: https://bugs.openjdk.java.net/browse/JDK-8215320 This change will also be included in the upcoming Maintenance Reviews of the Java SE 8 and 11 Platform JSRs. See [2] for more information. I have also included the raw diffs below: diff -r 8829e86def29 closed/src/java.base/share/specs/security/standard-names.md --- a/closed/src/java.base/share/specs/security/standard-names.md Thu Dec 20 14:21:16 2018 -0500 +++ b/closed/src/java.base/share/specs/security/standard-names.md Wed Jan 02 15:39:12 2019 -0500 @@ -20,6 +20,10 @@ The Java SE Security API requires and uses a set of standard names for algorithms, certificate and keystore types. +Names that are added to subsequent Java SE versions of this +specification also apply to this version of the specification if the +Security APIs that those names are defined for are supported. + In some cases naming conventions are given for forming names that are not explicitly listed, to facilitate name consistency across provider implementations. Items in angle brackets (such as `` and --Sean [1] https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-December/000308.html
RE: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9
Hi, Anthony, Brad, Max, Sean, and Valerie. Just a quick thanks to all for your time in reviewing this issue. I pushed the changeset this morning to verona/stage. Expect the changeset to get to jdk9/* when we Verona is complete, later this summer. Regards, iris -Original Message- From: verona-dev [mailto:verona-dev-boun...@openjdk.java.net] On Behalf Of iris.cl...@oracle.com Sent: Monday, July 20, 2015 9:41 AM To: verona-...@openjdk.java.net Subject: hg: verona/stage/jdk: 8130696: Security Providers need to have their version numbers updated for JDK 9 Changeset: 165608bfa113 Author:iris Date: 2015-07-20 09:40 -0700 URL: http://hg.openjdk.java.net/verona/stage/jdk/rev/165608bfa113 8130696: Security Providers need to have their version numbers updated for JDK 9 Reviewed-by: ascarpino, mullan, valeriep, weijun, wetmore ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/Sun.java ! src/java.base/share/classes/sun/security/provider/VerificationProvider.java ! src/java.base/share/classes/sun/security/rsa/SunRsaSign.java ! src/java.base/share/classes/sun/security/ssl/JsseJce.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/JdkLDAP.java ! src/java.security.jgss/share/classes/sun/security/jgss/SunProvider.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/Provider.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/SunPCSC.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/UcryptoProvider.java ! src/jdk.deploy.osx/macosx/classes/apple/security/AppleProvider.java ! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/JdkSASL.java ! test/java/security/Provider/ProviderVersionCheck.java ! test/sun/security/util/Oid/S11N.java
RE: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9
Hi, Sean. Sorry for the delayed response. Thanks for your review. Great catch! I thought I'd checked the output for all of the failing security tests, but it looks like I missed that. I've created and tested a new changeset which addresses that problem. The changeset is off of verona/stage which was recently sync'd with jdk9-b72. In addition to the test fix, there are some minor changes from the first webrev (some files no longer need copyright updates, com.sun.security.sasl.gsskerb.JdkSASL changes added). http://cr.openjdk.java.net/~iris/verona/8130696/webrev.1 Let me know if you have any additional concerns. Thanks, iris -Original Message- From: Sean Mullan Sent: Thursday, July 09, 2015 9:23 AM To: Weijun Wang; Iris Clark; security-dev@openjdk.java.net Subject: Re: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 The Version variable on line 73 of S11N.java should be all lowercase: int version = Integer.valueOf(v); otherwise it should not compile. --Sean On 07/08/2015 11:57 PM, Weijun Wang wrote: Hi Iris The change to S11N.java looks fine. Thanks Max On 07/08/2015 01:48 AM, Iris Clark wrote: Hi. Please review changes to resolve the following bug: 8130696: Security Providers need to have their version numbers updated for JDK 9 (Verona) Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev The constructor invocation for every Provider implementation contains a hard-coded value for the version, 1.9d, which it compares to java.specification.version. Verona [0,1] changes the system property from 1.9 to 9. The provider's version should be changed to 9.0d. Many regression tests in the jdk repository fail due to this bug. Test groups with failing tests detecting this problem include jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have verified that all providers modified by 8030823 [2] have been updated. After review, the changeset will be pushed to verona/stage [3]. The changeset will go to jdk9/dev when Verona is complete later this summer. Thanks, Iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 [3] http://hg.openjdk.java.net/verona/stage
RE: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9
Hi, Max. Thanks for taking the time to review. Regards, iris -Original Message- From: Weijun Wang Sent: Wednesday, July 08, 2015 8:57 PM To: Iris Clark; security-dev@openjdk.java.net Subject: Re: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 Hi Iris The change to S11N.java looks fine. Thanks Max On 07/08/2015 01:48 AM, Iris Clark wrote: Hi. Please review changes to resolve the following bug: 8130696: Security Providers need to have their version numbers updated for JDK 9 (Verona) Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev The constructor invocation for every Provider implementation contains a hard-coded value for the version, 1.9d, which it compares to java.specification.version. Verona [0,1] changes the system property from 1.9 to 9. The provider's version should be changed to 9.0d. Many regression tests in the jdk repository fail due to this bug. Test groups with failing tests detecting this problem include jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have verified that all providers modified by 8030823 [2] have been updated. After review, the changeset will be pushed to verona/stage [3]. The changeset will go to jdk9/dev when Verona is complete later this summer. Thanks, Iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 [3] http://hg.openjdk.java.net/verona/stage
RE: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9
Hi, Valerie. Sorry for the delayed response. Thanks for reviewing.The original webrev was based off of verona/stage which was synch'd to jdk9-b70. The file you reference wasn't in the repository yet. Since that time, verona/stage has been sync'd with jdk9-b72 . Here's the new changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev.1 In addition to modifying com.sun.security.sasl.gsskerb.JdkSASL, I also updated the S11N.java test to address Sean's concern. Other security updates pulled in by the sync made some of my copyright updates unnecessary, so those have been removed as well. Let me know if you have any additional concerns. Regards. iris From: Valerie Peng Sent: Wednesday, July 08, 2015 7:24 PM To: HYPERLINK mailto:security-dev@openjdk.java.netsecurity-dev@openjdk.java.net Subject: Re: RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9 Is the Verona repo sync'ed to the latest OpenJDK? The webrev seems to be missing the provider JdkSASL inside the following file src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/JdkSASL.java The rest looks good. Valerie On 7/7/2015 10:48 AM, Iris Clark wrote: Hi. Please review changes to resolve the following bug: 8130696: Security Providers need to have their version numbers updated for JDK 9 (Verona) Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev The constructor invocation for every Provider implementation contains a hard-coded value for the version, 1.9d, which it compares to java.specification.version. Verona [0,1] changes the system property from 1.9 to 9. The provider's version should be changed to 9.0d. Many regression tests in the jdk repository fail due to this bug. Test groups with failing tests detecting this problem include jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have verified that all providers modified by 8030823 [2] have been updated. After review, the changeset will be pushed to verona/stage [3]. The changeset will go to jdk9/dev when Verona is complete later this summer. Thanks, Iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 [3] http://hg.openjdk.java.net/verona/stage
RFR: (s) 8130696: Security Providers need to have their version numbers updated for JDK 9
Hi. Please review changes to resolve the following bug: 8130696: Security Providers need to have their version numbers updated for JDK 9 (Verona) Bug: https://bugs.openjdk.java.net/browse/JDK-8130696 Changeset: http://cr.openjdk.java.net/~iris/verona/8130696/webrev The constructor invocation for every Provider implementation contains a hard-coded value for the version, 1.9d, which it compares to java.specification.version. Verona [0,1] changes the system property from 1.9 to 9. The provider's version should be changed to 9.0d. Many regression tests in the jdk repository fail due to this bug. Test groups with failing tests detecting this problem include jdk_security, jdk_management, jdk_jmx, and jdk_net. These tests now pass. I have verified that all providers modified by 8030823 [2] have been updated. After review, the changeset will be pushed to verona/stage [3]. The changeset will go to jdk9/dev when Verona is complete later this summer. Thanks, Iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f1066af06fa0 [3] http://hg.openjdk.java.net/verona/stage
RE: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
Hi, Jeremy. As an Author, you can create a changeset but you can't push to the repo until you're a Committer. Additional details about the differences between Author and Committer may be found here [1,2]. The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the hg commit -u jmanson ... to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of hg export -g which would preserve information in the changeset header including the author, commit comment, etc. Thanks, iris [1]: http://openjdk.java.net/projects/#project-author [2]: http://openjdk.java.net/projects/#project-committer -Original Message- From: Jeremy Manson [mailto:jeremyman...@google.com] Sent: Tuesday, May 27, 2014 2:19 PM To: Vincent Ryan Cc: OpenJDK; core-libs-dev Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in? Jeremy On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan vincent.x.r...@oracle.com wrote: Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your fix if you wish. On 27 May 2014, at 21:09, Jeremy Manson jeremyman...@google.com wrote: Just like the title says - every time you generate a new private key, you leak a little memory. Webrev here: http://cr.openjdk.java.net/~jmanson/8044059/webrev/ This is probably the wrong mailing list for this bug, but I expect someone on this list will point me in the right direction. Jeremy
RE: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX
So overall it looks good to me and should be pushed to the staging forest once you hear from others that commented previously. I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov. Alan, please correct me if I'm wrong. Thanks, iris -Original Message- From: Alan Bateman Sent: Tuesday, November 26, 2013 9:03 AM To: Volker Simonis Cc: Vladimir Kozlov; 2d-...@openjdk.java.net; serviceability-...@openjdk.java.net; security-dev; ppc-aix-port-...@openjdk.java.net; awt-...@openjdk.java.net; Java Core Libs; net-dev Subject: Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX On 26/11/2013 16:23, Volker Simonis wrote: Hi, thanks to everybody for the prompt and helpful reviews. Here comes the final webrev which incorporates all the corrections and suggestions from the second review round: http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ I've successfully build (and run some smoke tests) with these changes on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, MacOSX and AIX (5.3, 7.1). I've skimmed over the last webrev with focus on: NetworkingLibraries.gmk where I see this is now fixed for all platforms. net_util.* and the platform specific net_util_md.* where I see you've added platformInit so it's much cleaner. UnixNativeDispatcher.c where the error translation is now removed (and looks fine). So overall it looks good to me and should be pushed to the staging forest once you hear from others that commented previously. -Alan
