Re: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin

On 9/6/19 6:29 PM, Claes Redestad wrote: The original default hardcoded list includes many more forms. What is the diff of the jlink-plugin generated classes before and after this patch? I wonder if we should include a few other method types in HelloClassList like float parameter. 

Re: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin

Hi Mandy, On 2019-09-06 21:07, Mandy Chung wrote: Hi Claes, The patch looks much straightforward than I expected. thanks? :-) The original default hardcoded list includes many more forms.  What is the diff of the jlink-plugin generated classes before and after this patch? I wonder if

Re: Comments on jpackage (JEP 343)

Please see https://bugs.openjdk.java.net/browse/JDK-8211182 IIRC there were also concerns that jpackage was not the right place to be defining this, and also I think Andy wrote some boiler plate code that demonstrated it was not needed for at least some of these use cases. Andy (?) So not

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

On 9/6/19 2:20 PM, Brent Christian wrote: Update webrev is here: http://cr.openjdk.java.net/~bchristi/8212117/webrev11/ with changes to jvm.h, MethodHandles.java, and Class.java. Looks good. Mandy

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi, Mandy On 9/5/19 6:03 PM, Mandy Chung wrote: On 9/5/19 5:09 PM, Brent Christian wrote: jvm.h 349 * Link the 'arg' class (unless ClassForNameDeferLinking is set) I suggest to drop "(unless ...)" phrase because the flag is temporary. Sure, good idea. jni.cpp The implementation of

Re: jpackage on MacOs: app from pkg cannot write files and create directories inside itself

Hi Andrey, Writing to  /Application on macOS or "Program Files" on Windows requires admin privileges. It is very uncommon when application stores temp files or setting files modifiable by user inside installation folder. For temp files I will recommend to use system provided temp folder. For

Re: JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io

Hi Joe, > On Sep 6, 2019, at 11:12 AM, Joe Darcy wrote: > > First part of a multi-part cleanup effort please review > > JDK-8230723: Remove default constructors from java.lang and java.io > > webrev: http://cr.openjdk.java.net/~darcy/8230723.0/ >

Re: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin

Hi Claes, The patch looks much straightforward than I expected. The original default hardcoded list includes many more forms.  What is the diff of the jlink-plugin generated classes before and after this patch? I wonder if we should include a few other method types in HelloClassList like

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

Martin's rules for test methods: - never have more than 100 millisecond total expected runtime - never have more than 12 millisecond blocking time for any single operation - yet be able to survive a one-time 5 second thread suspension at any time --- adjusting wait time looks like an

Re: RFR: 8230662: Remove dead code from MethodTypeForm

Looks good.  This is a good simplification. thanks Mandy On 9/5/19 7:41 AM, Claes Redestad wrote: Hi, I noticed some unused methods in java.lang.invoke.MethodTypeForm and ended up with a rather substantial cleanup after pulling that particular thread for a bit:

JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io

Hello, First part of a multi-part cleanup effort please review     JDK-8230723: Remove default constructors from java.lang and java.io     webrev: http://cr.openjdk.java.net/~darcy/8230723.0/     CSR: https://bugs.openjdk.java.net/browse/JDK-8230724 Patch below. The default constructors on

[14] RFR: 8230284: Accounting currency format support does not cope with explicit number system.

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8230284 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ The original enhancement for the accounting currency format support

Re: RFR(s): 8228580: DnsClient TCP socket timeout

On Thu, 5 Sep 2019 at 18:59, Florian Weimer wrote: > > But I think in the UDP case, the client will retry. I think the total > timeout in the TCP case should equal the total timeout in the UDP case. > That's what I'm going to implement for glibc. The difference is that in > the TCP case, the

jpackage on MacOs: app from pkg cannot write files and create directories inside itself

Hello. I use jpackage (Build 14-jpackage+1-35) to bundle my Swing-based app for MacOS. Whereas DMG format works pretty well, PGK bundle has a serious issue. When I install the app from PKG, it cannot write files or create directories inside itself. I have /resource directory for my app that has a

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

> On 6 Sep 2019, at 17:11, Martin Buchholz wrote: > > Bigger picture: all of this timeout-fiddling infrastructure should be in a > test library. It's not easy! > > test/jdk/java/util/concurrent/tck effectively has its own test library, for > historical reasons. Agreed. It is not an easy

Re: 8229333: java/io/File/SetLastModified.java timed out

An alternative would be to increase the required memory: @@ -23,6 +23,7 @@ /* @test @bug 4091757 6652379 8177809 + @requires os.maxMemory >= 16G @summary Basic test for setLastModified method */ Thanks, Brian > On Aug 28, 2019, at 10:51 AM, Lance Andersen > wrote: > > Looks

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

> On 6 Sep 2019, at 15:59, Martin Buchholz wrote: > > I took another look at LdapTimeoutTest.java. Many thanks! > I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one > timeout that is long enough to "never happen". I'm still advocating the 10 > second value. > > I was

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

Bigger picture: all of this timeout-fiddling infrastructure should be in a test library. It's not easy! test/jdk/java/util/concurrent/tck effectively has its own test library, for historical reasons. On Fri, Sep 6, 2019 at 7:59 AM Martin Buchholz wrote: > I took another look at

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

I took another look at LdapTimeoutTest.java. I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one timeout that is long enough to "never happen". I'm still advocating the 10 second value. I was surprised to see LEFT_MARGIN. We just fixed Thread.sleep, so we have no known

Re: RFR: 8230662: Remove dead code from MethodTypeForm

Vladimir, thanks for reviewing! /Claes On 2019-09-06 15:48, Vladimir Ivanov wrote: Looks good. Best regards, Vladimir Ivanov On 05/09/2019 17:41, Claes Redestad wrote: Hi, I noticed some unused methods in java.lang.invoke.MethodTypeForm and ended up with a rather substantial cleanup after

Re: RFR: 8230662: Remove dead code from MethodTypeForm

Looks good. Best regards, Vladimir Ivanov On 05/09/2019 17:41, Claes Redestad wrote: Hi, I noticed some unused methods in java.lang.invoke.MethodTypeForm and ended up with a rather substantial cleanup after pulling that particular thread for a bit:

Re: RFR(s): 8228580: DnsClient TCP socket timeout

Milan, In order to simulate the "Address already in use" scenario I did this: TcpDnsServer(int port) { try { * new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); serverSocket = new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); } catch

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

If you ran the specdiff and saw nothing, I'm fine with that. Looks good. > On 5 Sep 2019, at 19:28, Julia Boes wrote: > > Hi, > > Thanks for your comments, Lance and Pavel. > > The copyright will be updated before pushing, as Daniel suggested. > > To address the tag alignment, I adjusted the

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

Martin, thanks for having a look at it. I'd appreciate if you could have a look at the timeout measuring mechanics in assertCompletion/assertIncompletion specifically, maybe to spot something that is grossly inadequate. I tried to accommodate some usual suspects of timeout measurements

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

Hi Julia, It looks fine., thank you for doing this Best Lance > On Sep 5, 2019, at 2:28 PM, Julia Boes wrote: > > Hi, > > Thanks for your comments, Lance and Pavel. > > The copyright will be updated before pushing, as Daniel suggested. > > To address the tag alignment, I adjusted the

Re: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string

Hi, Anyone able to review please? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leon...@uk.ibm.com From: Andrew Leonard/UK/IBM To: core-libs-dev@openjdk.java.net Cc: james.las...@oracle.com Date: 02/09/2019