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.

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 !

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

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

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:janvier but was:January Summary: Tests against the data of the French locale are not valid as

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

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

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: scolebou...@joda.org !

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

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:

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 !

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

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

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 !

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 !

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

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 !

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 !

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

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 !

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:

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 !

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:

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:

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

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 <roger.ri...@oracle.com> wrote: Found

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: 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

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:

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,

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

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

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

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

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, so it look

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

t 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, On 8/14/2018 10:59 A

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

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 code

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

and 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: [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

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

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

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.

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 used

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

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

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,

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, dean.l...@oracle.com 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: 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,

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

e 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, at 10:33

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

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    

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

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: [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,

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

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

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

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: 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

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

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

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

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

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

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

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

/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 core-libs-...@openjdk.java.net). Within the JDK and JDK tests there are multiple implementations to encode and decode hexadecimal strings to byte

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 +++

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 core-libs-...@openjdk.java.net). 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: 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.

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]

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 ; NULL > 028d:03 82 01 ; BIT STR

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

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

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 ; NULL > 028d:03 82 01 ; B

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 [v3]

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 ; NULL > 028d:03 82 01 ; B

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

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

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

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 ; NULL > 028d:03 82 01 ; B

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())' invocation

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

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

Re: RFR: 8252055: Use java.util.HexFormat in java.security [v2]

> The java.util.HexFormat methods for formatting and parsing replace a number > of adhoc hex parsing and formatting methods in sun.security implementation > classes. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Update c

RFR: 8250255: Use java.util.HexFormat in java.security

The java.util.HexFormat methods for formatting and parsing replace a number of adhoc hex parsing and formatting methods in sun.security implementation classes. - Commit messages: - 8250255: Use java.util.HexFormat in java.security Changes:

Integrated: 8252055: Use java.util.HexFormat in java.security

On Thu, 17 Dec 2020 20:45:57 GMT, Roger Riggs wrote: > The java.util.HexFormat methods for formatting and parsing replace a number > of adhoc hex parsing and formatting methods in sun.security implementation > classes. This pull request has now been integrated. Changeset: 68f2ac

RFR: 8258796: [test] Apply HexFormat to tests for java.security

Followup to the addition of java.util.HexFormat. Uses of adhoc hexadecimal conversions are replaced with HexFormat. Redundant utility methods are modified or removed. In a few places the data being printed is ASN.1 and the test utility HexPrinter with the ASNFormatter is added. -

Re: RFR: 8258796: [test] Apply HexFormat to tests for java.security [v2]

> Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1 and the test utility > HexPrinter with the ASNFormatter i

Re: RFR: 8258796: [test] Apply HexFormat to tests for java.security

On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote: > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1

Integrated: 8258796: [test] Apply HexFormat to tests for java.security

On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote: > Followup to the addition of java.util.HexFormat. > Uses of adhoc hexadecimal conversions are replaced with HexFormat. > Redundant utility methods are modified or removed. > In a few places the data being printed is ASN.1

Re: RFR: 8259021 avoid double racy reads from non-volatile fields of SharedSecrets [v2]

On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote: >> See: https://bugs.openjdk.java.net/browse/JDK-8259021 >> See also discussion in thread: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html > > Peter Levart has updated the pull request incrementally with one

Re: RFR: 8265426: Update java.security to use instanceof pattern variable [v5]

On Thu, 6 May 2021 14:42:20 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the >> `java.security` package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull

Re: RFR: 8265426: Update java.security to use instanceof pattern variable [v3]

On Thu, 6 May 2021 11:52:15 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the >> `java.security` package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull

Re: RFR: 8267123: Remove RMI Activation

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Tue, 29 Jun 2021 19:35:40 GMT, Weijun Wang wrote: >> Using a HashSet could use the callerClass as the key and be a stable >> reference for having given the message. >> or use a ConcurrentHashMap>, boolean> and avoid any separate >> synchronization that would be needed with a HashSet or

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Tue, 29 Jun 2021 18:47:23 GMT, Daniel Fuchs wrote: >> Add a cache to record which sources have called `System::setSecurityManager` >> and only print out warning lines once for each. > > src/java.base/share/classes/java/lang/System.java line 337: > >> 335: =

  1   2   >