Re: RFR: 8219548 Re: Faulty Null-Check Suspected in ToolProvider

2019-02-21 Thread Alan Bateman
On 21/02/2019 20:34, Lance Andersen wrote: Here is the webrev of the patch from Philipp. I did not change the name of the test() method as it was not necessary http://cr.openjdk.java.net/~lancea/8219548/webrev.00/ This looks okay to me, probably should get Jon to review as he added this API.

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

2019-02-21 Thread David Holmes
On 22/02/2019 4:55 am, Mikael Vidstedt wrote: The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. Sorry I really don't like it. The wrappers obfuscate and make complicated something that is not at all complicated. I have to re-read the new code 3 times to figu

JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes

2019-02-21 Thread Joe Darcy
Hello, Internally jdeprscan initializes a set of strings of releases supporting deprecation with removal. Currently those releases are JDK 9 and subsequent values. The lists is explicitly initialized and must be updated at the start of a release, which adds to the maintenance cost of starting

Re: RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder.

2019-02-21 Thread Mandy Chung
On 2/21/19 4:49 PM, 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 enhancement removes the use of jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of i

RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder.

2019-02-21 Thread Andy Herrick
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 enhancement removes the use of jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of invoking jlink directly thru the ToolProvider

Re: RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0

2019-02-21 Thread Mandy Chung
On 2/20/19 3:10 PM, Vicente Romero wrote: Please review the simple patch to fix [1] at [2]. The patch is simply adding a comment to the API, (javadoc) to sync it with the implementation. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8219480 [2] http://cr.openjdk.java.net/~vro

Re: can't create an image using jpackage and javafx

2019-02-21 Thread Michael Hall
> On Feb 20, 2019, at 12:57 PM, Edoardo Panfili wrote: > > LSOpenURLsWithRole() failed with error -10810 for the file > /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app. That sounds like maybe an error from the open command - not necessarily the application error. Does this from Ter

RFR: 8219548 Re: Faulty Null-Check Suspected in ToolProvider

2019-02-21 Thread Lance Andersen
Here is the webrev of the patch from Philipp. I did not change the name of the test() method as it was not necessary http://cr.openjdk.java.net/~lancea/8219548/webrev.00/ > On Feb 15, 2019, at 6:59 PM, Philipp Kunz wrote: > > Hi Lance, > > See attached patch. > > Regards, > Philipp > > >

Re: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm

2019-02-21 Thread Alan Bateman
On 21/02/2019 19:55, Igor Ignatyev wrote: : Alan, you are right, this test is a JNI test and should be moved to hotspot/runtime/jni. more details in my answer to the same comment in David's email. in two words, I accidentally looked at another test. Can you double check that it is actually usi

Re: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm

2019-02-21 Thread Igor Ignatyev
> On Feb 21, 2019, at 12:19 AM, Alan Bateman wrote: > On 21/02/2019 05:19, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> 40 lines changed: 17 ins; 2 del; 21 mod; >> Hi all, >> >> could you please review this small patch which moves tests from te

Re: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm

2019-02-21 Thread Igor Ignatyev
> On Feb 21, 2019, at 12:11 AM, David Holmes wrote: > > Hi Igor, > > On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> 40 lines changed: 17 ins; 2 del; 21 mod; >> Hi all, >> could you please review this small patch which mov

can't create an image using jpackage and javafx

2019-02-21 Thread Edoardo Panfili
Hi, I'm trying to create an image of an application that uses JavaFX on macOS The builds goes well but when I try to launch the application the result is "LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/workspace/asteroidi/Asteroids.app." the proj

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

2019-02-21 Thread Mikael Vidstedt
The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. (not a Reviewer) Cheers, Mikael > On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: > > To me thread function wrappers look preferable to platform specific JavaMain > signature. Consider this webrev with wra

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

2019-02-21 Thread Roger Riggs
Thanks for the updates,  Looks good. On 02/21/2019 12:06 PM, Naoto Sato wrote: Hi Roger, Sorry for the missing the bug id in the subject, added it. Better late than never :-) On 2/20/19 6:41 PM, Roger Riggs wrote: Hi Naoto, The fix looks fine. The direction for new tests is to give them

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

2019-02-21 Thread Roger Riggs
Hi Andrew, Is there a test case?  Since the initialization is a side effect of static initialization, it might be hard to trigger just one of those paths.  How was it discovered? Thanks, Roger On 02/21/2019 11:57 AM, Alan Bateman wrote: On 21/02/2019 16:49, Roger Riggs wrote: Hi Andrew, I

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

2019-02-21 Thread Dmitry Chuyko
To me thread function wrappers look preferable to platform specific JavaMain signature. Consider this webrev with wrappers: http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/ In some cases JavaMain is called in the same thread and its result is returned from JLI_Launch. ContinueInNewThread

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

2019-02-21 Thread Mandy Chung
Hi Adam, On 2/14/19 3:16 AM, Adam Farley8 wrote: Hi Mandy, Apologies for the delay. Same here as I returned from vacation yesterday. Could you review this cdiff as a proposal for the jtreg test? Made sense to modify the existing test set for MethodHandle rather than add a new one. Yes i

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

2019-02-21 Thread Naoto Sato
Hi Roger, Sorry for the missing the bug id in the subject, added it. Better late than never :-) On 2/20/19 6:41 PM, Roger Riggs wrote: Hi Naoto, The fix looks fine. The direction for new tests is to give them functional names, not bugids. Is there a suitable name? Renamed the test case, a

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

2019-02-21 Thread Alan Bateman
On 21/02/2019 16:49, Roger Riggs wrote: Hi Andrew, I can sponsor; it looks correct to me. Any other reviewers? It looks right but would be good to have a test case that demonstrates the issue. -Alan

Re: Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

2019-02-21 Thread Roger Riggs
Hi Andrew, I can sponsor; it looks correct to me. Any other reviewers? Thanks, Roger On 02/19/2019 11:24 AM, Andrew Leonard wrote: Please can I request a sponsor for this fix to ReflectionFactory where langReflectAccess is not always correctly initialized. Webrev: http://cr.openjdk.java

Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

2019-02-21 Thread Naoto Sato
+1 Please follow the appropriate process to push the changeset. Naoto On 2/21/19 2:27 AM, Seán Coffey wrote: Looks good. regards, Sean. On 21/02/2019 08:54, Deepak Kejriwal wrote: Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.ja

Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

2019-02-21 Thread Naoto Sato
+1 Please follow the appropriate process to push the changeset. Naoto On 2/21/19 2:24 AM, Seán Coffey wrote: Thanks. Looks good to me. regards, Sean. On 21/02/2019 09:10, Deepak Kejriwal wrote: Hi Sean, The webrev I shared was not correct. I have corrected the webrev.02 now. Please check

RE: RFR 8213031: (zipfs) Add support for POSIX file permissions

2019-02-21 Thread Langer, Christoph
Hi Alan, here is the next iteration: http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ I focused on your comments regarding implementation details: > I'm not sure about using ${user.name} and "" as default. > Have you looked at using the zip file owner/group (or owner/owner on > Windows) a

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

2019-02-21 Thread Lindenmaier, Goetz
Hi Andrew, > Ok. However, if you have the appropriate method bytecodes and the BCI at > which the exception occurred then I'm not sure why you would need ASM. I implemented it in C++ at first. I was asked to investigate an implementation in Java by the reviewers. Thanks! Goetz > Also, it wa

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

2019-02-21 Thread Andrew Dinn
On 21/02/2019 12:57, Lindenmaier, Goetz wrote: > thanks for giving this advice! It confirms the problems I see. You are welcome. > For the context: > The idea was to implement this in Java using StackWalker and > ASM. If I had the right bytecodes, and the right starting point, > ASM would be h

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

2019-02-21 Thread Lindenmaier, Goetz
Hi Andrew, thanks for giving this advice! It confirms the problems I see. For the context: I proposed better NPE exception messages: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/ The original implementation is C++ and walks the metaspace given the method* and BCI where the except

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

2019-02-21 Thread Andrew Dinn
The latest JEP and draft implementation now address the 3 outstanding issues: 1) 2-arg force method now uses integer start offset and length force(int from, int length) 2) length is checked against buffer limit rather than capacity 3) start position and length checks are implemented using Obj

Re: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

2019-02-21 Thread Seán Coffey
Looks good. regards, Sean. On 21/02/2019 08:54, Deepak Kejriwal wrote: Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ Thanks for review. Regards, Deepak -Original

Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

2019-02-21 Thread Seán Coffey
Thanks. Looks good to me. regards, Sean. On 21/02/2019 09:10, Deepak Kejriwal wrote: Hi Sean, The webrev I shared was not correct. I have corrected the webrev.02 now. Please check now:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ Regards, Deepak *From:*Seán Cof

RE: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

2019-02-21 Thread Deepak Kejriwal
Hi Sean,   The webrev I shared was not correct. I have corrected the webrev.02 now. Please check now:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/   Regards, Deepak   From: Seán Coffey Sent: Thursday, February 21, 2019 2:11 PM To: Deepak Kejriwal ; Naoto Sato ;

RE: RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710

2019-02-21 Thread Deepak Kejriwal
Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/ Thanks for review. Regards, Deepak -Original Message- From: Naoto Sato Sent: Wednesday, February 20, 2019 11:07 PM

Re: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

2019-02-21 Thread Seán Coffey
Deepak, this exception message in new test still needs correction: 166 "Character.isLetter(int) failed for codepoint " 167 + Integer.toHexString(cp)); As an aside, there's probably no need for such specific exception messages in a tes

RE: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915

2019-02-21 Thread Deepak Kejriwal
Hi Naoto, Corrected the exception message. Please find below updated version of webrev:- http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/ Thanks for review. Regards, Deepak -Original Message- From: Naoto Sato Sent: Wednesday, February 20, 2019 11:06 PM To: Deepak K

Re: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm

2019-02-21 Thread Alan Bateman
On 21/02/2019 05:19, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html 40 lines changed: 17 ins; 2 del; 21 mod; Hi all, could you please review this small patch which moves tests from test/jdk/vm? there are 16 tests in test/jdk/vm directory. all but J

Re: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm

2019-02-21 Thread David Holmes
Hi Igor, On 21/02/2019 3:19 pm, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html 40 lines changed: 17 ins; 2 del; 21 mod; Hi all, could you please review this small patch which moves tests from test/jdk/vm? I find some of these tests - the runtime on