hg: jdk8/tl/jdk: 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate

Changeset: acaa256e3f7c Author:rriggs Date: 2013-08-16 13:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acaa256e3f7c 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate Summary: align Meiji start date with lib/calendar.properties to

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 53819fd0ab61 Author:rriggs Date: 2013-08-16 11:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53819fd0ab61 8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing 8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed. Summ

hg: jdk8/tl/jdk: 8011944: Sort fails with ArrayIndexOutOfBoundsException

Changeset: 07585a2483fa Author:rriggs Date: 2013-08-26 11:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07585a2483fa 8011944: Sort fails with ArrayIndexOutOfBoundsException Summary: Increase the size of pending stack and add test cases Reviewed-by: alanb ! src/share/clas

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 292d93f32aa1 Author:rriggs Date: 2013-09-11 10:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/292d93f32aa1 8024164: JSR310 serialization should be described in details Summary: The serialized-form.html should specify the stream format for interoperability Revie

hg: jdk8/tl/jdk: 8024618: Issues with French locale on compact1, 2: expected: but was:

Changeset: 672f349fbad7 Author:rriggs Date: 2013-09-12 10:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/672f349fbad7 8024618: Issues with French locale on compact1,2: expected: but was: Summary: Tests against the data of the French locale are not valid as conformance te

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 3255a4e348a1 Author:rriggs Date: 2013-09-14 13:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3255a4e348a1 8023639: Difference between LocalTime.now(Clock.systemDefaultZone()) and LocalTime.now() executed successively is more than 100 000 000 nanoseconds for s

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 01b8604e8268 Author:rriggs Date: 2013-08-22 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b8604e8268 8024896: Refactor java.time serialization tests into separate subpackage Summary: Move serialization tests to .serial subpackage Reviewed-by: sherman Contr

hg: jdk8/tl/jdk: 7 new changesets

Changeset: 1de0fac9b962 Author:rriggs Date: 2013-08-29 20:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1de0fac9b962 8023764: Optimize Period addition Summary: Optimise plus/minus for common cases Reviewed-by: sherman Contributed-by: [email protected] ! src/share/clas

hg: jdk8/tl/jdk: 2 new changesets

Changeset: e3b70e601c1c Author:rriggs Date: 2013-10-09 11:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3b70e601c1c 8024612: java/time/tck/java/time/format/TCKDateTimeFormatters.java failed Summary: The test should be using the Locale.Category.FORMAT to verify the test

hg: jdk8/tl/jdk: 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter

Changeset: d42fe440bda8 Author:rriggs Date: 2013-10-09 13:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d42fe440bda8 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Summary: Add appendValueReduced method based on a ChronoLocalDate to provide co

hg: jdk8/tl/jdk: 3 new changesets

Changeset: ea422834f880 Author:rriggs Date: 2013-09-26 23:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea422834f880 8025720: Separate temporal interface layer Summary: Remove ZoneId and Chronology from TemporalField interface Reviewed-by: sherman Contributed-by: scolebou

hg: jdk8/tl/jdk: 8026516: javadoc errors in java.time

Changeset: 36fe6a9bd43e Author:rriggs Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36fe6a9bd43e 8026516: javadoc errors in java.time Summary: Corrected links to TemporalQuery and TemporalField.resolve Reviewed-by: mduigou, darcy, lancea ! src/share/c

hg: jdk8/tl/jdk: 8026183: minor documentation problems in java.lang.invoke; ...

Changeset: 456a9b199208 Author:rriggs Date: 2013-10-17 13:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/456a9b199208 8026183: minor documentation problems in java.lang.invoke 8015808: Typo in MethodHandle javadoc Summary: Fix typos and javadoc markup and extraneous paragr

hg: jdk8/tl/jdk: 8025828: Late binding of Chronology to appendValueReduced

Changeset: 7a947daa8f51 Author:rriggs Date: 2013-10-18 16:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a947daa8f51 8025828: Late binding of Chronology to appendValueReduced Summary: Add a listener to the parseContext called when the Chronology changes Reviewed-by: sherm

hg: jdk8/tl/jdk: 3 new changesets

Changeset: e2b814e68956 Author:rriggs Date: 2013-10-22 15:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2b814e68956 8024686: Cleanup of java.time serialization source Summary: optimize serialized form of OffsetTime, OffsetDateTime; correct order of modifiers Reviewed-by

hg: jdk8/tl/jdk: 8026982: javadoc errors in core libs

Changeset: 4bb758a77fd7 Author:rriggs Date: 2013-10-22 17:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bb758a77fd7 8026982: javadoc errors in core libs Summary: Cleanup of javadoc -Xlint errors Reviewed-by: lancea, mduigou, darcy, mullan, mchung ! src/share/classes/jav

hg: jdk8/tl/jdk: 8024458: DataInput.readDouble refers to "readlong" instead of "readLong"

Changeset: 04f071a95c29 Author:rriggs Date: 2013-11-07 20:56 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04f071a95c29 8024458: DataInput.readDouble refers to "readlong" instead of "readLong" Summary: fix the typo Reviewed-by: lancea, chegar, dxu ! src/share/classes/java/i

hg: jdk8/tl/jdk: 8028041: Serialized Form description of j.l.String is not consistent with the implementation

Changeset: df2f7f288353 Author:rriggs Date: 2013-11-08 17:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df2f7f288353 8028041: Serialized Form description of j.l.String is not consistent with the implementation Summary: Replaced incorrect description with reference to the

hg: jdk8/tl/jdk: 8028092: Lint cleanup of java.time.format

Changeset: 3add16c86970 Author:rriggs Date: 2013-11-09 14:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3add16c86970 8028092: Lint cleanup of java.time.format Summary: correct declarations and add @SuppressWarnings Reviewed-by: darcy, lancea ! src/share/classes/java/time

hg: jdk8/tl/jdk: 8028014: Doclint warning/error cleanup in javax.management

Changeset: ebe27e1a2e2d Author:rriggs Date: 2013-11-12 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ebe27e1a2e2d 8028014: Doclint warning/error cleanup in javax.management Summary: Improve generated html by fixing doclint warnings Reviewed-by: sla, jbachorik ! src/sh

hg: jdk8/tl/jdk: 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again

Changeset: 3f47e393e1dd Author:rriggs Date: 2013-11-19 13:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f47e393e1dd 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again Summary: Correct to use the test.class.path in

hg: jdk8/tl/jdk: 8028019: AWT Doclint warning/error cleanup

Changeset: 3e95aadb479f Author:rriggs Date: 2013-12-03 16:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e95aadb479f 8028019: AWT Doclint warning/error cleanup Summary: Fix numerious javadoc and html errors and warnings Reviewed-by: yan ! src/share/classes/java/applet/Ap

hg: jdk8/tl/jdk: 8029551: Add value-type notice to java.time classes

Changeset: fe3383582427 Author:rriggs Date: 2013-12-11 16:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe3383582427 8029551: Add value-type notice to java.time classes Summary: Add warning about identity of value types and reference to ValueBased.html Reviewed-by: brian

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 7186275e6ef1 Author:rriggs Date: 2013-12-20 13:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7186275e6ef1 8030002: Enhance deserialization using readObject Reviewed-by: sherman, chegar, scolebourne ! src/share/classes/java/time/Duration.java ! src/share/classe

hg: jdk8/tl/jdk: 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours()

Changeset: 1b503dd54b95 Author:rriggs Date: 2014-01-07 11:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b503dd54b95 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Summary: Correct specification for Duration.toDays, toHours Reviewed-by: l

RFR 80044461: Cleanup new Boolean and single character strings

A quick sanity check please for these cleanup changes to remove uses of new Boolean and using chars instead of single character strings contributed by Otávio Gonçalves de Santana. These changes update multiple classes in the jdk9-dev repo (except client packages). webrev: http://cr.openjdk.ja

Re: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf

Hi Max, The release note is fine though it would more complete if it contained a link to the krb5_conf.html where the behavior is described. The original issue https://bugs.openjdk.java.net/browse/JDK-8210821 describes the behavior if set to 'false', while the release note is written describi

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Hi Dean, typo AccessController line788: "annocations" The implementations of doPrivileged(PrivilegedExceptionAction action) and doPrivileged(PrivilegedAction action) Could be a bit more similar since except for the exception wrapping they are the same. 309 return executePrivileged(action, n

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Hi Dean, Looks ok, I have no better suggestion. Roger On 11/05/2018 01:51 PM, [email protected] wrote: Hi Roger.  Thanks for looking at this. On 11/5/18 7:21 AM, Roger Riggs wrote: Hi Dean, typo AccessController line788: "annocations" Fixed. The implementations of do

Re: FYI: new javadoc tag to document system properties

Hi, If a system property is defined and specified as supported then it needs a public declaration and specification as part of the public class or package documentation. Checking for and adding the tag will be a good way to reconfirm property definitions are in the right place. Would it be r

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

Looks fine Joe I hadn't realized example.com was registered for that purpose.  :) On 11/26/2018 04:38 PM, joe darcy wrote: 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

Re: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow

Hi, The Cleaner approach should be reasonable and we'd like to avoid introducing new uses of finalize that will need to be removed later. Tracking it to see if there are any issues is a good idea. Thanks, Roger On 11/30/2018 01:03 PM, Xue-Lei Fan wrote: Hi Weijun, I think you made a signific

Re: RFR 8214568: Use {@systemProperty} for definitions of system properties

Hi, Thanks for converting the package doc. There is XML commented text in the package-info.java that should be removed. It would show up in the javadoc. And there are links that can now use {@link}. It probably worth  % make docs-javadoc and checking the result in images/docs/api. Thanks, R

Re: RFR 8214568: Use {@systemProperty} for definitions of system properties

he comments are still leftovers from some previous process and here's a chance to clean it up. Can {@link} be used to link to a URL? I only know about using it to link to class and method names. ok as is, @link is only within the javadoc. Thanks, Roger Thanks, Max On Dec 13, 2018

Re: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings

Hi Sean, Typically, fixed serialization streams are encoded in the source as byte arrays. That keeps binary content out of the repo and provides a place for the comments. Roger On 04/02/2019 09:50 AM, Sean Mullan wrote: On 4/2/19 9:44 AM, Weijun Wang wrote: On Apr 2, 2019, at 9:33 PM, Sea

Re: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

Hi, If this were java.base, we would use doPrivilege to ignore the policy and place specific limits. Encumbering the default policy with conditions needed by a trusted subsystem seems like distributing what should be a local implementation issue. $.02, Roger On 6/20/19 2:23 AM, Mandy Chung w

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Claes, I would recommend using writeReplace to serialize the PermissionCollection so the serialized form does not change. Though these are unlikely to be serialized, it will be less likely to trigger some interoperability issue between different version. It may need to be documented that se

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Looks good, Thanks, Roger On 8/15/19 11:22 AM, Claes Redestad wrote: (adding back core-libs-dev) Hi Roger, seems easy enough to add a writeReplace: http://cr.openjdk.java.net/~redestad/8229773/webrev.02 /Claes On 2019-08-15 16:54, Roger Riggs wrote: Hi Claes, I would recommend using

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

+1 On 8/16/19 12:51 PM, Sean Mullan wrote: +1 from me as well. --Sean On 8/16/19 12:38 PM, Alan Bateman wrote: On 16/08/2019 13:30, Claes Redestad wrote: How about this: http://cr.openjdk.java.net/~redestad/8229773/webrev.03/ Also simplified BuiltinClassLoader#getPermissions since the jr

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

Hi Joe, Looks fine to me. Roger 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 of this new annotation type is to allow serialization-rel

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

Sean, I think that's the other EncryptionKey. The one in src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java isn't. Roger On 9/26/19 3:35 PM, Sean Mullan wrote: - Krb5Context.java 1394 @SuppressWarnings("serial") // Not statically typed as Serializable 1395

Re: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k

Hi Ivan, Raising it to work up to the spec'd limit is a good approach. Do we have a way to test this?  Aka: There should be a test. Roger On 2/10/20 8:07 PM, Ivan Gerasimov wrote: Thank you Michael! It's a good point about maximum length. Here's the updated webrev with the new System prope

Re: RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k

, which was not possible before the fix. I'll add a noreg-hard label to the bug. [1] http://hg.openjdk.java.net/jdk/jdk/file/73bcb3e4e596/test/jdk/sun/security/smartcardio/TestTransmit.java With kind regards, Ivan On 2/11/20 6:46 AM, Roger Riggs wrote: Hi Ivan, Raising it to work up t

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

Looks fine. On 3/13/20 11:42 AM, Pavel Rappo wrote: Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentat

Re: RFR 15: 8243010: Test support: Customizable Hex Printer (and security test updates)

To correct an oversight to include security-dev in the reviews... Several security tests were modified to use the HexPrinter instead of HexDumpEncoder. Please review[2] and comment on a new Hex printing utility to support OpenJDK tests. The usefulness of a hex printing has been discussed fro

Re: [15] RFR 8247964: All log0() in com/sun/org/slf4j/internal/Logger.java should be private

Looks good. Good to catch these early. Thanks, Roger On 6/20/20 10:47 AM, Weijun Wang wrote: The 3 newly added log0() methods in com/sun/org/slf4j/internal/Logger.java are declared public. This is a stupid typo. In fact, in the comment at the beginning of that class [1] I specifically pointe

Re: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection

Hi Claes, Its correct as is but I would have written it without duplicating the 'permsMap.get(p.getClass())' invocation and as a single method (unless the inlining of getPermissionCollection(p,create)) is important. A patch on top of yours: diff --git a/src/java.base/share/classes/java/secur

Re: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection

path taken, since it means the permission is not implied and the performance largely irrelevant. I'll simplify as you suggested. /Claes On 2020-06-22 23:03, Roger Riggs wrote: Hi Claes, Its correct as is but I would have written it without duplicating the 'permsMap.get(p.getClass())&#

Re: Fix for Javadoc errors in java.base

Looks fine Julia On 8/18/20 1:02 PM, Julia Boes wrote: Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 23:55:41.953638446 +0530 +++ new/src/java.base/sha

RFR 8252055: Use java.util.Hex encoder and decoder in java.security

Please review using the java.util.Hex api in security related classes. (The review of the API is being done on the [email protected]). Within the JDK and JDK tests there are multiple implementations to encode and decode hexadecimal strings to byte arrays. Hex encoders and decoders

Re: RFR 8252055: Use java.util.Hex encoder and decoder in java.security

8/20/2020 8:14 AM, Roger Riggs wrote: Please review using the java.util.Hex api in security related classes. (The review of the API is being done on the [email protected]). Within the JDK and JDK tests there are multiple implementations to encode and decode hexadecimal strings to

RFR: 8252523: Add ASN1 Formatter to work with HexPrinter

# 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 structure

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

7 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE > [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ;

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v3]

7 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE > [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ;

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v4]

7 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE > [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ;

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

On Mon, 21 Sep 2020 00:19:53 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Small cleanups to javadoc and code > > test/lib/jdk/test/lib/hexdump/ASN1Form

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

On Mon, 21 Sep 2020 14:04:19 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Small cleanups to javadoc and code > > Just some comments based on the output example. A

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

On Tue, 29 Sep 2020 14:27:29 GMT, Weijun Wang wrote: >> Are there any other comments or suggestions? > > Can you post an example output of that cert? What about indefinite length? > (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, > 2, 'c', 'd', 0, 0) For your example the output is: : 24 80

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v5]

7 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE > [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NUL

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

On Tue, 29 Sep 2020 15:20:13 GMT, Jamil Nimeh wrote: > Also in that last example, it seems to suggest that the second octet string > is nested within the first one since it > sits at a second indent layer. They are both primitives completely covered by > their two byte values so shouldn't they

Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

On Tue, 29 Sep 2020 19:35:42 GMT, Jamil Nimeh wrote: > Regarding the end-of-content identifier, that looks good. Thanks for fixing > the indentation for the right-side ASN.1 > interpretation of the bytes. My only remaining question is whether the > corresponding hex dumps on the left should mat

Integrated: 8252523: Add ASN.1 Formatter to work with test utility HexPrinter

On Sun, 20 Sep 2020 13:54:02 GMT, Roger Riggs wrote: > # 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 fo

RFR: 8251989: Hex formatting and parsing utility

java.util.HexFormat utility: - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase - Static factories and builder methods to create HexFormat copies with modified parameters. - Consistent naming of methods for conversion of byte arrays to fo

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

Hi Chris, Looks fine. The change in exception message is more informative than the previous exception message. Roger On 10/7/2015 2:19 PM, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is

Re: RFR 9: 8169416: SSLSessionImpl finalize overhead

Adding security-dev... Please review this change to remove an ineffective finalizer for SSLSessions. The finalizer removes bindings from the SSLSession of a table that is also freed when the SSLSession is being freed. There is no point in removing them explicitly. It only delays freeing memory

RFR 8184744 : Replace finalizer in crypto classes with Cleaner

Please review replacing finalize with java.lang.ref.Cleaner in a few simple cases. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ Thanks, Roger

Re: RFR 8184744 : Replace finalizer in crypto classes with Cleaner

-finalize-8184744/ Thanks, Roger On 8/3/2017 9:58 AM, Roger Riggs wrote: Please review replacing finalize with java.lang.ref.Cleaner in a few simple cases. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ Thanks, Roger

Re: RFR 8184744 : Replace finalizer in crypto classes with Cleaner

have opinion. There are very few of these cases and I think it is better to keep the code close to the use. If there's good place to put a method for this purpose, let me know. Thanks, Roger Mandy On Aug 3, 2017, at 1:01 PM, Roger Riggs wrote: Found a race in the tests between the Cl

Re: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck

Hi Ivan, One idea to consider is an indirection that spreads the work over multiple Cache implementations. Similar to what ConcurrentHashMap does, doing an early fan out to multiple Caches based on the key. If it was keyed to the same key as the cache, it would be able to take advantage of re-

RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

Please review cleanup replacements of System.getProperty("line.separator") with System.lineSeparator(). It uses the line separator from System instead of looking it up in the properties each time. Also fixed one javadoc @see reference. The affected files are in several packages: com/sun/cry

Re: RFR 8200152: KerberosString should use UTF-8 by default

Hi, I've seen a variety of interpretations of non-standard input for parsing booleans and it is likely to cause confusion across properties. I'd prefer that we converge on the interpretation used in the Boolean.parseBoolean. Which uses:  "true".equalsIgnoreCase(s); Better yet, call Boolean.

Re: RFR 8200152: KerberosString should use UTF-8 by default

Never mind, the latest webrev is great! On 4/9/2018 9:03 AM, Roger Riggs wrote: Hi, I've seen a variety of interpretations of non-standard input for parsing booleans and it is likely to cause confusion across properties. I'd prefer that we converge on the interpretation u

Re: RFR for 6443578 and 6202130: UTF-8 in Manifests

Hi Phillip, Just a reminder that OpenJDK can *only* accept patches via cr.openjdk.java.net (as an author) or inline or attached in email. Thanks, Roger On 5/2/18 9:12 PM, Philipp Kunz wrote: Hi, Here is patch for 6443578 and 6202130 also in webrev form. http://files.paratix.ch/jdk/6372077

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

Hi, "final" is a important modifier of the method signature and if the CSR and the implementation are different it might raise a question about which is the correct signature when the JCK folks write tests. It is pretty lightweight process to return the CSR to draft and update it and finaliz

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Hi Chris, It is very unusual for the processing of system properties to do *any* parsing except for delimiters including removing spaces, etc.  It complicates the handling and sets a bad precedent that makes it more complex for users and developers to know how to set property values. The whit

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

keep the original non-whitespace description. Case-insensistive compares are another slippery slope but make a bit more sense for usability. $.02, Roger On 7/20/18 10:18 AM, Chris Hegarty wrote: Roger, On 20 Jul 2018, at 14:52, Roger Riggs wrote: Hi Chris, It is very unusual for the

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

, Roger Riggs wrote: Hi Chris, It is important to be clear about how whitespace is treated and within the java.security file there are other uses that explicitly define how whitespace is used. Right, and the usages are already inconsistent. Nothing we can do about that now. I am more concerned

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

Hi Joe, Looks fine.  I 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) Regards, Roge

Re: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security property

+1 On 8/7/18 9:09 AM, Sean Mullan wrote: On 8/7/18 3:09 AM, Alan Bateman wrote: On 06/08/2018 20:23, Sean Mullan wrote: After further evaluation of the new jdk.includeInExceptions security property originally introduced in JDK-8204233 [1] and further generalized in JDK-8207846 [2], I felt tha

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

Hi Max, It may be useful to include in the descriptions a reminder that if no ObjectInputFilter is supplied the global filter is used.  Details in ObjectInputStream. Typically, the @throws clauses that are not full sentences do not include a final period "." For consistency with the existing

Re: RFR 8209416: Refactoring GetPropertyAction calls in JGSS

Hi Max, It might be useful to be a bit more consistent about putting the property name on the same line as the privilegedGetProperty. It would help finding/grepping for the targets of privileged actions. For example, Grep would not find the one in sun/security/krb5/Config.java:824-825 or sun/s

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

Hi Max, On 8/14/2018 12:29 AM, Weijun Wang wrote: On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote: Hi Max, It may be useful to include in the descriptions a reminder that if no ObjectInputFilter is supplied the global filter is used. Details in ObjectInputStream. The new getObject

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote: It may be useful to include in the descriptions a reminder that if no ObjectInputFilter is supplied the global filter is used. Details in ObjectInputStream. The new getObject() methods with an ObjectInputFilter does not allow it to be null,

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

Hi, On 8/14/2018 10:59 AM, Weijun Wang wrote: s/initial process-wide filter/system filter/? yes Roger --Max [1] 8202675   Replace process-wide terminology in serial filtering to be consistent Regards, Roger

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

[1] https://bugs.openjdk.java.net/browse/JDK-8193887 On Aug 14, 2018, at 11:19 PM, Roger Riggs wrote: Hi, On 8/14/2018 10:59 AM, Weijun Wang wrote: s/initial process-wide filter/system filter/? yes Roger --Max [1]8202675 Replace process-wide terminology in serial filtering to be consisten

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

Hi Max, On 8/21/18 11:19 AM, Weijun Wang wrote: Also, I think the specification of the getObject() method should be updated to say that the system filter is used to validate the deserialized object. I realize that this was a previous side-effect of adding the system filter and not part of thi

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

the updated webrev at http://cr.openjdk.java.net/~weijun/8193859/webrev.01 Changes only in doc, including 1) The "2018-8-15 updates" in the CSR [1] 2) formatting Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8193887 On Aug 14, 2018, at 11:19 PM, Roger Riggs wrote: Hi,

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

mean during deserialization an untrusted object could be created that have a reference to the stream itself? On Aug 23, 2018, at 10:12 PM, Roger Riggs wrote: Hi, The original basis for the security manager check was to ensure that the filter could not be replaced by untrusted code including co

Re: [12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

edge cases. Thanks, Roger On 8/23/18 12:19 PM, Weijun Wang wrote: But calling getObject(filter) effectively overrides the system filter, is that a problem? On Aug 23, 2018, at 11:51 PM, Roger Riggs wrote: Hi Max, Yes, the stream is passed to the readObject method of the classes being

Re: Conceptual feedback on new ECC JEP

Hi, In general, System properties should be avoided, they add complexity to configurations and especially if they change sensitive behavior.  In any case, the defaults should be secure-by-default; not the other way around. Perhaps two different providers, one secure and one more secure. $.02

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

Hi Sean, Looks good. I would quibble with System.java:335-6 "Java virtual machine does not allow a security manager" I would say only "a security manager is not allowed to be set dynamically." There is no need to identify the Java virtual machine.  The VM itself has nothing to do with it.

Re: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed [v2]

On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote: >> Remove the use of Security Manager from jstatd. >> Add use of an ObjectInputFilter to restrict RMI. >> >> Also we can undo the property-setting Launcher.gmk change from: 8279007: >> jstatd fails to start because SecurityManager is disabled

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 rriggs (Reviewer). --

Re: RFR: 8272777: Clean up remaining AccessController warnings in test library

On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") > annotation (which has already been widely applied). Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7328

Re: RFR: 8282279: Interpret case-insensitive string locale independently

On Wed, 23 Feb 2022 00:05:58 GMT, Xue-Lei Andrew Fan wrote: > The String.toUpperCase() or String.toLowerCase() method is locale sensitive, > and may produce unexpected results if used for strings that are intended to > be interpreted locale independently. The use of the two methods had been >

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 We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client mo

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 rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7268

Re: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2]

On Tue, 8 Mar 2022 05:51:21 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204: >> >>> 202: } catch (GeneralSecurityException | java.io.IOException e) >>> { >>> 203: throw new SSLHandshakeException( >>> 204:

Re: RFR: 8282819: Deprecate Locale class constructors

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `i

Re: RFR: 8282819: Deprecate Locale class constructors

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `i

  1   2   >