RFR: JDK-8231281: Consider eliminating --identifier option

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Removed --identifier option, since it only usage is to specify identifier when generating pkg on macOS and as default value for

[Ping] 8229333: java/io/File/SetLastModified.java timed out

> Begin forwarded message: > > From: Brian Burkhalter > Subject: Re: 8229333: java/io/File/SetLastModified.java timed out > Date: September 6, 2019 at 9:36:39 AM PDT > To: core-libs-dev > > An alternative would be to increase the required memory: > > @@ -23,6 +23,7 @@ > > /* @test >

Re: RFR: jsr166 integration 2019-09

On Mon, Sep 23, 2019 at 11:08 PM David Holmes wrote: > Except when I run it through our test system ReservedStackTest is still > failing :( > > I tested it initially when Fred proposed it and that went fine. It also > passes for me locally on Linux. > I committed the changes other than for

Re: Formatting rules for exception messages

2019/9/27 6:23:54 -0700, Florian Weimer : > * mark reinhold: > >> 2019/3/25 5:24:37 -0700, Florian Weimer : >>> Are there any guidelines for formatting exception messages? >>> >>> In particular, I'm interested in the case when the exception message >>> is a (clipped) sentence. Is it supposed to

Re: RFR 8231427 (test) Warning cleanup in tests of java.io.Serializable

Hi Roger, Generally looks fine. Adding some comments about why the @SuppressWarnings annotations were being applied might help future readers of the code. Cheers, -Joe On 9/27/2019 10:02 AM, Roger Riggs wrote: Please review cleanup of tests in java/io/Serializable. There are warnings for

Re: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java

Hi Patrick, This looks much better. Best lance > On Sep 27, 2019, at 10:53 AM, Patrick Concannon > wrote: > > Hi Lance, > > > > Thanks for your feedback. I've added in those changes, and you can find them > in the new webrev linked below. > > webrev:

Re: RFR [14/java.xml] 8016914: CoreDocumentImpl.setXmlVersion NPE

Thanks Lance! On 9/27/19 10:47 AM, Lance Andersen wrote: Hi Joe, The change looks fine as does the test. Best Lance On Sep 27, 2019, at 12:29 PM, Joe Wang > wrote: Please review a fix to the NPE issue. This is part of the work on the XML declaration related

Re: RFR [14/java.xml] 8016914: CoreDocumentImpl.setXmlVersion NPE

Hi Joe, The change looks fine as does the test. Best Lance > On Sep 27, 2019, at 12:29 PM, Joe Wang wrote: > > Please review a fix to the NPE issue. This is part of the work on the XML > declaration related issues. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8016914 > webrev:

RFR 8231427 (test) Warning cleanup in tests of java.io.Serializable

Please review cleanup of tests in java/io/Serializable. There are warnings for mis-use of serialization methods and fields; some are intentional as they are the focus of the tests. The test code had quite a few warnings about raw types, deprecated methods, and missing serialVersionUIDs, and

RFR: 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call

Hi, I think that JDK-8194653 [0] affects jdk/jdk and it doesn't specific to FileSystems.getDefault. I'm starting a new thread/bug as the original issue marked as resolved ([3]) Ryan, thanks for investigation and providing a test [1]! But the test fails in the same way if the

RFR [14/java.xml] 8016914: CoreDocumentImpl.setXmlVersion NPE

Please review a fix to the NPE issue. This is part of the work on the XML declaration related issues. JBS: https://bugs.openjdk.java.net/browse/JDK-8016914 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8016914/webrev/ Thanks, Joe

Re: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module

Hmm. That would seem to be more consistent. I'll take another look and likely file a follow-up bug since I had already pushed JDK-8231546 when I saw this message. Thanks for the careful review, -Joe On 9/26/2019 12:58 PM, Chris Hegarty wrote: +1. Should the @serial javadoc tag be removed?

Re: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java

Hi Lance, Thanks for your feedback. I've added in those changes, and you can find them in the new webrev linked below. webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.01/ Kind regards, Patrick On 26/09/2019 13:36, Lance Andersen wrote: Hi Patrick, Overall I think

Re: RFR (XS) 8230415 : Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection

Hi Ivan, The fix looks good. Good catch. --Sean On 8/30/19 7:32 PM, Ivan Gerasimov wrote: Hello! In the two implementations of PermissionCollection.implies(Permission), all the permissions are traversed, and their corresponding bit mask are checked. For example, here's a snippet from

Re: Formatting rules for exception messages

* mark reinhold: > 2019/3/25 5:24:37 -0700, Florian Weimer : >> Are there any guidelines for formatting exception messages? >> >> In particular, I'm interested in the case when the exception message >> is a (clipped) sentence. Is it supposed to start with a capital >> letter? >> >> If the

Re: CharsetEncoder.maxBytesPerChar()

Like Ulf, I am sometimes annoyed by the use of the "character" misnomer throughout the API docs, and would support an effort to use "character" the way that unicode.org uses it. "char" no longer represents a Unicode character, but at least it provides a short clear name, in the Java language, for

Re: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs.

Hi! I'd appreciate a review of this one. Thanks in advance! See below. On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote: > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u backport. The OpenJDK 11u patch does not apply > > cleanly after