Re: RFR: JDK-8212091 : Move native code under platform specific folders and files

Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. Webrev updated with files moved, instead of add/remove. Thanks, Alexander On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: On 2019-02

Re: Faulty Null-Check Suspected in ToolProvider

diff -r 7c17199fa37d src/java.base/share/classes/java/util/spi/ToolProvider.java --- a/src/java.base/share/classes/java/util/spi/ToolProvider.java Fri Feb 15 08:21:08 2019 -0500 +++ b/src/java.base/share/classes/java/util/spi/ToolProvider.java Sat Feb 16 00:57:54 2019 +0100 @@ -126,8 +126,9 @@

Re: Faulty Null-Check Suspected in ToolProvider

Hi Philipp This probably makes sense to update. Can you also update the ToolProviderTest.java to add a test for the changes Thank you Best Lance > On Feb 15, 2019, at 4:43 PM, Philipp Kunz wrote: > >

jpackage Packaging Tool Early Access Update 3

A third EA build (Build 17) of jpackage tool is available at https://jdk.java.net/jpackage/ This release contains fixes to the following: JDK-8217894: jpackage CLI syntax changes JDK-8217792: Investigate what modules are included JDK-8217793: Modular jars in jpackage are not working JDK-8217687

[13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218960 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ The CONFIG message was generated because CLDRCalendarDataProviderImpl was returning null for locale

Re: RFR: JDK-8217802: Invalid Option warning message.

Looks good. On 2/15/2019 7:30 AM, Andy Herrick wrote: 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). This is a simple fix to the unsupported Option warning message, and also fixes a problem when t

Faulty Null-Check Suspected in ToolProvider

Hi, There has always been an implicit null-check for args by the for loop attempting to iterate but the check seems to be intended and wrong for the elements. See attached patch. >From the comment to args, "the command-line arguments for the tool", I guess it makes sense to conclude that these sho

Manifest ignores last line if not terminated by line break

Hi, Manifest parsing an input stream given to the constructor or the read method ignores the contents of the last line unless terminated with a line break. In course of my attempt to fix 8217375, I found that Manifest ignores the last line when not terminated with a line break whereas ManifestDig

Re: JDK-6982173: Small problem causing thousands of wasted CPU hours

I think this situation is a mess. The “general contract” of a Collection, I believe, is that it contains zero or more identified member objects, as defined by appropriate equals() method. I know this is hard to specify precisely, but I presume we all “know it when we see it”. There is value to

Re: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable

Hi Lance, On 15/02/2019 20:07, Lance Andersen wrote: Hi Daniel so it looks like it was an intentional decision to  support the NPE but looks like an oversight to update the javadoc? Well I guess it was intentional to return false for null in StreamHandlers and FileHandlers, but the spec said

Re: RFR: JDK-8217802: Invalid Option warning message.

Looks good. -- Kevin On 2/15/2019 7:30 AM, Andy Herrick wrote: 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). This is a simple fix to the unsupported Option warning message, and also fixes a prob

Re: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable

Hi Daniel so it looks like it was an intentional decision to support the NPE but looks like an oversight to update the javadoc? I think you could go either way with this as I gotta believe their is a very low compatibility impact either way… > On Feb 15, 2019, at 1:46 PM, Daniel Fuchs wrote

Re: RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable

Hi Mandy, Here is the new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/ It is much nicer than the previous version [1], but unfortunately it makes the following JCK tests fail: api/java_util/logging/MemoryHandler/IsLoggable.html api/java_util/logging/MemoryHandler/Publis

Re: JDK-6982173: Small problem causing thousands of wasted CPU hours

On 2/14/19 9:30 AM, Alan Snyder wrote: Care must be exercised if this method is used on collections that do not comply with the general contract for {@code Collection}. So, what does this mean? Are we catering to incorrect implementations? I think this is a quote from the specification of

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi Goetz, Just a couple of things if you go that route (of placeholder String):   56 private static final String MESSAGE_PLACEHOLDER = "NPE_MESSAGE_PLACEHOLDER"; Here, the initializer of that constant should create a private instance of String:     private static final String MESSAGE_

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Andrew, > On 15 Feb 2019, at 16:51, Andrew Dinn wrote: > > The latest round of changes to the JEP and draft implementation are now > available for review: > > JEP:http://openjdk.java.net/jeps/8207851 > webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/ I'm only following this is

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

The latest round of changes to the JEP and draft implementation are now available for review: JEP:http://openjdk.java.net/jeps/8207851 webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/ Latest Changes: After a very helpful discussion with Alan at FOSDEM I borrowed some hints from him

RFR: JDK-8217802: Invalid Option warning message.

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). This is a simple fix to the unsupported Option warning message, and also fixes a problem when the new "--installer-type" option is used when not in "c