Re: RFR(S): 8252407: Build failure with gcc-8+ and asan
Hi Kim, Sorry for the delay. This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation warning. Other warnings we talked before, which are unable to completely fix in different version of gcc, I have to use pragma to suppress them as a workaround. This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric
Re: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier
On Wed, 23 Sep 2020 02:49:29 GMT, Weijun Wang wrote: >> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the >> parameters field instead of encoding a >> Null tag. > > I don't quite understand what the test is for. The bug is about encoding but > the test seems to be decoding the > certificates. Does the test fail before this fix and succeed after it? This is because the encoding of Algorithm Identifier incorrectly adds two NULL tags to the parameters field in the canned certificate. (There are two Algorithm Identifiers in the cert, with each NULL tag containing two bytes: tag + length.) I use the length of an encoded certificate (x509Cert.getEncoded().length) to verify that the certificate contains an extra 4 bytes to hold the two NULL tags. Therefore, the certificate without the fix should be 4 bytes (5 bytes if one byte alignment is applied) longer in length than the certificate with the fix. - PR: https://git.openjdk.java.net/jdk/pull/312
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]
On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and the commit now in the PR. To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. - PR: https://git.openjdk.java.net/jdk/pull/45
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v4]
> Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I > believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name > in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if > fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them > sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate - Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=03 Stats: 753 lines in 65 files changed: 153 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45
Re: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier
On Tue, 22 Sep 2020 22:21:20 GMT, Hai-May Chao wrote: > This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the > parameters field instead of encoding a > Null tag. I don't quite understand what the test is for. The bug is about encoding but the test seems to be decoding the certificates. Does the test fail before this fix and succeed after it? - PR: https://git.openjdk.java.net/jdk/pull/312
RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier
This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a Null tag. - Commit messages: - 8252377: Incorrect encoding for EC AlgorithmIdentifier Changes: https://git.openjdk.java.net/jdk/pull/312/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=312&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252377 Stats: 217 lines in 2 files changed: 216 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/312/head:pull/312 PR: https://git.openjdk.java.net/jdk/pull/312
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2]
On Tue, 22 Sep 2020 15:36:24 GMT, Daniel Fuchs wrote:
>> No, It is not used.
>> However, I'd like to leave it as is (it is mentioned in the documentation as
>> unsupported value).
>> Otherwise, TlsChannelBindingType enum will have one element only and should
>> be simplified/removed in all places. In
>> this case, it would be double work to add TlsChannelBindingType enum back in
>> the future if "tls-unique" required. If
>> required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType
>> enum
>
> I was suggesting to keep TlsChannelBindingType but remove TLS_UNIQUE;
> However, I'm OK to keep things as is: this is an
> internal API. I wonder if it would deserve a comment:
> /**
> * Channel binding on the basis of TLS Finished message
> */
> // TLS_UNIQUE is defined by RFC 5929 but is not supported by the
> current LDAP stack.
> TLS_UNIQUE("tls-unique"),
Thank you. Added suggested comment.
-
PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2]
On Tue, 22 Sep 2020 15:11:57 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8245527: version.01
>
> src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
> line 156:
>
>> 154: if (props != null) {
>> 155: // TLS Channel Binding
>> 156: byte[] tlsCB =
>> (byte[])props.get("jdk.internal.sasl.tlschannelbinding");
>
> You can say the name is defined in another class in another module. If we
> really want to rename it one day we will know
> where it's from.
Thank you. Comment is added
> src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java
> line 389:
>
>> 387: int acceptorAddressType = getAddrType(acceptorAddress,
>> 388: (channelBinding instanceof TlsChannelBindingImpl)?
>> 389:
>> CHANNEL_BINDING_AF_UNSPEC:CHANNEL_BINDING_AF_NULL_ADDR);
>
> Normally we put a white space around "?" and ":".
Thank you. Fixed.
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
> line 82:
>
>> 80: /**
>> 81: * Parse value of "com.sun.jndi.ldap.tls.cbtype" property
>> 82: * @param cbType
>
> Please add a `@return` here, esp, about null.
Added @return with comments
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
> line 137:
>
>> 135: public TlsChannelBindingType getType() {
>> 136: return cbType;
>> 137: }
>
> Add a new line here.
Fixed
-
PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2]
> Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support > for Java GSS/Kerberos. > Initial review is available at core-devs: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel > binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: 8245527: version.01 - Changes: - all: https://git.openjdk.java.net/jdk/pull/278/files - new: https://git.openjdk.java.net/jdk/pull/278/files/3f4ae08c..8b135f48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00-01 Stats: 15 lines in 4 files changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v3]
> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the > annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > : 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons > 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d:02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d:05 00; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021:31 0b; SET [11] > 0023: 30 09 ; SEQUENCE > [9] > 0025:06 03 55 04 06 ; OBJECT > ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d:30 0e; SEQUENCE > [14] > 005f: 06 ; OBJECT > ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d:30 1e; SEQUENCE [30] > 006f: 17 ; UTCTIME > [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME > [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22; SEQUENCE [290] > 00df: 30 ; SEQUENCE > [13] > 00e0: 0d ; > 00e1:06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID > [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING > [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201:a3 7b;
Integrated: 8253208: Move CDS related code to a separate class
On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a > separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 This pull request has now been integrated. Changeset: c1df13b8 Author:Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/c1df13b8 Stats: 218 lines in 23 files changed: 53 ins; 119 del; 46 mod 8253208: Move CDS related code to a separate class Reviewed-by: mchung, iklam - PR: https://git.openjdk.java.net/jdk/pull/261
Re: RFR: 8253208: Move CDS related code to a separate class [v3]
On Mon, 21 Sep 2020 22:24:15 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a >> separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional > commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/261
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote:
> Hi,
>
> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
> for Java GSS/Kerberos.
> Initial review is available at core-devs:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
> This version removes "tls-unique" CB type from the list of possible channel
> binding types. The only supported type is
> "tls-server-end-point"
> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311
>
> Thank you
> Alexey
I'm mostly OK with the SASL/JGSS part, except for the small nits in this
comment. I'm not an expert on
HandshakeCompletedListener.
src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java
line 156:
> 154: if (props != null) {
> 155: // TLS Channel Binding
> 156: byte[] tlsCB =
> (byte[])props.get("jdk.internal.sasl.tlschannelbinding");
You can say the name is defined in another class in another module. If we
really want to rename it one day we will know
where it's from.
src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java
line 389:
> 387: int acceptorAddressType = getAddrType(acceptorAddress,
> 388: (channelBinding instanceof TlsChannelBindingImpl)?
> 389:
> CHANNEL_BINDING_AF_UNSPEC:CHANNEL_BINDING_AF_NULL_ADDR);
Normally we put a white space around "?" and ":".
src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
line 82:
> 80: /**
> 81: * Parse value of "com.sun.jndi.ldap.tls.cbtype" property
> 82: * @param cbType
Please add a `@return` here, esp, about null.
src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
line 137:
> 135: public TlsChannelBindingType getType() {
> 136: return cbType;
> 137: }
Add a new line here.
-
PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
On Tue, 22 Sep 2020 15:17:23 GMT, Alexey Bakhtin wrote:
>> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
>> line 63:
>>
>>> 61: * Channel binding on the basis of TLS Finished message
>>> 62: */
>>> 63: TLS_UNIQUE("tls-unique"),
>>
>> Is that still used? If not maybe it should be removed?
>
> No, It is not used.
> However, I'd like to leave it as is (it is mentioned in the documentation as
> unsupported value).
> Otherwise, TlsChannelBindingType enum will have one element only and should
> be simplified/removed in all places. In
> this case, it would be double work to add TlsChannelBindingType enum back in
> the future if "tls-unique" required. If
> required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType
> enum
OK
-
PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
On Tue, 22 Sep 2020 14:47:35 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
>> for Java GSS/Kerberos.
>> Initial review is available at core-devs:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
>> This version removes "tls-unique" CB type from the list of possible channel
>> binding types. The only supported type is
>> "tls-server-end-point"
>> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311
>>
>> Thank you
>> Alexey
>
> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
> line 63:
>
>> 61: * Channel binding on the basis of TLS Finished message
>> 62: */
>> 63: TLS_UNIQUE("tls-unique"),
>
> Is that still used? If not maybe it should be removed?
No, It is not used.
However, I'd like to leave it as is (it is mentioned in the documentation as
unsupported value).
Otherwise, TlsChannelBindingType enum will have one element only and should be
simplified/removed in all places. In
this case, it would be double work to add TlsChannelBindingType enum back in
the future if "tls-unique" required. If
required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum
-
PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
On Tue, 22 Sep 2020 14:41:57 GMT, Daniel Fuchs wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support >> for Java GSS/Kerberos. >> Initial review is available at core-devs: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel >> binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 994: > >> 992: } >> 993: >> 994: private CompletableFuture tlsHandshakeCompleted = > > Should be `final`? Thank you. Agree. It should be final. - PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote:
> Hi,
>
> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
> for Java GSS/Kerberos.
> Initial review is available at core-devs:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
> This version removes "tls-unique" CB type from the list of possible channel
> binding types. The only supported type is
> "tls-server-end-point"
> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311
>
> Thank you
> Alexey
src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 994:
> 992: }
> 993:
> 994: private CompletableFuture tlsHandshakeCompleted =
Should be `final`?
src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java
line 63:
> 61: * Channel binding on the basis of TLS Finished message
> 62: */
> 63: TLS_UNIQUE("tls-unique"),
Is that still used? If not maybe it should be removed?
-
PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support > for Java GSS/Kerberos. > Initial review is available at core-devs: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel > binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey Thanks for the PR Alexey! Let me run a last round of testing - and if that comes back clean I'll approve. Please don't integrate until you get a reviewer from security-libs too. best regards, -- daniel - PR: https://git.openjdk.java.net/jdk/pull/278
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and >> calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove >> from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to >> reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, >> secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, >> sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, >> sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 >> c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, >> X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one > additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac throw new IllegalStateException( new InvalidAlgorithmParameterException( "Curve not supported: Private: " + ((privNC != null) ? privNC.toString() : " unknown") + ", PublicKey:" + ((pubNC != null) ? pubNC.toString() : " unknown"))); src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 180: > 178: ((privNC != null) ? privNC.toString() : " > unknown") + > 179: ", PublicKey:" + > 180: ((pubNC != null) ? pubNC.toString() : " > unknown"))); Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be "unknown". - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and >> calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove >> from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to >> reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, >> secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, >> sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, >> sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 >> c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, >> X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one > additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac Build changes look good. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]
On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: >> Philippe Marschall has refreshed the contents of this pull request, and >> previous commits have been removed. The >> incremental views will show differences compared to the previous content of >> the PR. The pull request contains one new >> commit since the last revision: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by kvn (Reviewer). Have you run the JFR tests in test/jdk/jdk/jfr? - PR: https://git.openjdk.java.net/jdk/pull/45
