RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools

http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > 2375 lines changed: 322 ins; 1662 del; 391 mod Hi all, could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.pro

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Thanks for the reviews folks. I believe the following captures your recommended changes: http://cr.openjdk.java.net/~robm/8139965/webrev.02/ W.r.t. testing I think this area has been difficult to test traditionally. I'll have a dig through the existing testbase (and I'll get back to you) to see

Re: RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock

On Tue, Sep 4, 2018 at 12:02 PM, Roger Riggs wrote: > >> One sharp corner is that wait(0) waits forever, and TimeUnit conversion >> truncates. You can probably avoid those problems via TimeUnit.timedWait. >> >> Not trivial since a long cannot hold the combined time of millis(long) > and nanos (l

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

Daniel, Chris, Alan, thank you for your review. I've pushed it w/ Platfform::privilegedGetProperty method added to shorten lines in Platform.java Cheers, -- Igor > On Sep 4, 2018, at 6:08 AM, Daniel Fuchs wrote: > > Hi Igor, > > Nit: You could have introduced a > private static String getP

Re: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag

Hi Roger, I tentatively tried to return a shared zone within a cloned Calendar. One test failed: java/util/Calendar/CalendarRegression.Test4136399, where it makes sure that the cloned Calendar object hash code should be different for the better distribution. Although the comment does not refl

Re: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag

Hi Naoto, That access via reflection is going to go away sometime; so I'm not too concerned about maintaining compatibility of the internal implementation. I think I'd rather see the memory savings, however small. Let see if anyone else has a recommendation. Roger On 9/4/18 4:12 PM, Naoto Sa

Re: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag

Hi Roger, Yes, I considered that too, but did not change the behavior and just to maintain the field consistent. I agree that it would not be observable via the public Calendar API, but some apps (like how the submitter found it) may be doing something using reflection. Naoto On 9/4/18 12:3

Re: [PATCH] Simplification of TreeMap

Hi Sergey, I was also wondering why TreeMap doesn't just use a default comparator and always checks for null instead. The problem with your patch is that deserialized TreeMap instances which were serialized from a previous version would still have the comparator set to null, thus resulting in a N

Re: [PATCH] Simplification of TreeMap

Hi Sergey, if think the code is as it is because it's faster to check for the null comparator and have an ad-hoc code for this special case than using Comparator.naturalOrder(), obviously, it's not may be true anymore, so you should test that there is no perf regression when creating your patch.

Re: RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock

Thank you Roger! I'm not sure if it plays any significant role, but an unnecessary call to nanoTime() after wait(delay) could be avoided with the code like this: if (millis > 0) { if (isAlive()) { final long startTime = System.nanoTime(); long delay = millis

Re: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag

Hi Naoto, The spec for clone doesn't say whether the clone should share or not share the TimeZone. Did you consider that if sharedZone was true , *not* to clone the TimeZone? It would still get cloned when requested from getTimeZone(). This does seem somewhat safer not to change the cloning be

[PATCH] Simplification of TreeMap

Hi, currently (latest code of JDK 11) an instance of TreeMap created with no-arg contructor has nullable comparator i.e. utilizes no comparator. As it comes from the code, a TreeMap created with nullable comparator works exactly as a TreeMap created with comparator provided by Comparator.natur

Re: RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock

Hi Martin, Ivan, Thanks for the suggestions. Update in place: http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ On 8/29/2018 5:36 PM, Martin Buchholz wrote: Thanks for taking this on. Wait loops are notoriously hard to get right... One sharp corner is that wait(0) waits forever,

Re: RFR 8210285 : CharsetDecoder/Encoder's constructor does not reject NaN

On 9/4/18 9:40 AM, joe darcy wrote: Hello, Please also create a quick CSR to cover the behavioral change. Okay, here it is: https://bugs.openjdk.java.net/browse/JDK-8210377 Would you please help review it? Thanks in advance! Ivan Thanks, -Joe On 8/31/2018 5:17 PM, Ivan Gerasimov wro

[12] RFR: 8210142: java.util.Calendar.clone() doesn't respect sharedZone flag

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8210142 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8210142/webrev.00/ The fix is a simple one line change, which is to make the sharedZone field consistent with the cloned Tim

Re: RFR 8210285 : CharsetDecoder/Encoder's constructor does not reject NaN

Thanks everyone for reviewing! As suggested, I added a test to cover CharsetEncoder constructor and a sanity check that the constructor doesn't throw given valid arguments. http://cr.openjdk.java.net/~igerasim/8210285/01/webrev/ With kind regards, Ivan On 9/3/18 8:31 AM, Martin Buchholz wr

Re: [12] RFR of JDK-8209832: Refactor jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test

On 9/4/18 2:26 AM, Amy Lu wrote: I updated SetupGetCallerClass: http://cr.openjdk.java.net/~amlu/8209832/webrev.01/ Looks fine to me. Mandy

Re: StackWalker::getCallerClass throws UnsupportedOperationException

Thanks for reporting this.   I have created:    https://bugs.openjdk.java.net/browse/JDK-8210375 and will look into it. Mandy On 9/4/18 4:26 AM, Michael Rasmussen wrote: Hi StackWalker::getCallerClass can throw "UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSe

Re: RFR 8210318: idea.sh script doesn't work on Mac

Ah - thanks for the tip, I'll give that a try Maurizio On 04/09/18 18:50, Erik Joelsson wrote: Hello, $TARGET was just pseudo code. In your case it's $1.tmp. /Erik On 2018-09-04 10:34, Maurizio Cimadamore wrote: Hi Erik, would $TARGET be set by make? Maurizio On 04/09/18 16:55, Erik Jo

Re: RFR 8210318: idea.sh script doesn't work on Mac

Hello, $TARGET was just pseudo code. In your case it's $1.tmp. /Erik On 2018-09-04 10:34, Maurizio Cimadamore wrote: Hi Erik, would $TARGET be set by make? Maurizio On 04/09/18 16:55, Erik Joelsson wrote: Hello, When choosing a temp file in the build, we avoid using /tmp whenever possib

Re: RFR 8210318: idea.sh script doesn't work on Mac

Hi Erik, would $TARGET be set by make? Maurizio On 04/09/18 16:55, Erik Joelsson wrote: Hello, When choosing a temp file in the build, we avoid using /tmp whenever possible. A common pattern is instead to write to $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause an issue,

Re: RFR - 8210366: Typo in MethodHandles.Lookup: must be either be

Looks fine, Regards, Roger On 9/4/2018 12:39 PM, Daniel Fuchs wrote: Hi, This is a simple doc-only fix for a typo in MethodHandles.Lookup: 8210366: Typo in MethodHandles.Lookup: must be either be https://bugs.openjdk.java.net/browse/JDK-8210366 patch: ---

Re: RFR 8210285 : CharsetDecoder/Encoder's constructor does not reject NaN

Hello, Please also create a quick CSR to cover the behavioral change. Thanks, -Joe On 8/31/2018 5:17 PM, Ivan Gerasimov wrote: Hello! The javadoc for CharsetDecoder [1] states that an exception is thrown when a non-positive number is passed in as an argument. However we only reject negat

RFR - 8210366: Typo in MethodHandles.Lookup: must be either be

Hi, This is a simple doc-only fix for a typo in MethodHandles.Lookup: 8210366: Typo in MethodHandles.Lookup: must be either be https://bugs.openjdk.java.net/browse/JDK-8210366 patch: diff --git a/src/java.base/share/

Re: RFR 8210318: idea.sh script doesn't work on Mac

Hello, When choosing a temp file in the build, we avoid using /tmp whenever possible. A common pattern is instead to write to $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause an issue, /tmp/replacement is a global location which is potentially risky (file permissions, concurr

Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

Looks good to me. /Magnus > 4 sep. 2018 kl. 12:11 skrev Andrew Leonard : > > Hi Brian/Goetz, > Yes, that seems sensible. I have created a new webrev with fdlibm compiler > option disabled, and mediaLib code fixed: > http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ > I've built and te

Re: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection

Hi Vyom, IIUC, the issue only happens when connections (clients?) to the server are pooled. I assume the server may decide to close what it thinks is an idle connection at any time. So what we see here is actually a race between an open connection being retrieved from the pool, and the server de

Re: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection

On Friday 24 August 2018 08:52 PM, Chris Hegarty wrote: Hi Vyom, On 24/08/18 11:35, vyom tewari wrote: Hi All, Please review this simple fix below webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html bugid: https://bugs.openjdk.java.net/browse/JDK-8205330 This fix wil

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

I've added myself as a reviewer. You might want to set scope to "JDK". A CSR is approved by the CSR group after you finalize it. First you should propose it. If you think it's urgent or trivial, you can also fast-track it. Read https://wiki.openjdk.java.net/display/csr/Main for more details. Th

RE: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height

Hi Alan, thanks for your feedback (and thanks of course to all the others who commented on this proposal). As I've written in my first mail, this request came up because we had implemented getWidth/getHeigth APIs for console windows in our licensed VM to be used in a certain usage scenario. No

Re: RFR 8210318: idea.sh script doesn't work on Mac

The change looks fine to me Maurizio. Maybe you could append a .$$ to the temporary file name to make it less likely to overwrite something that already exists in /tmp - Michael. On 03/09/2018, 13:39, Maurizio Cimadamore wrote: Hi, following the latest updates to the idea.sh script, Mac users

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

Hi Igor, Nit: You could have introduced a private static String getProperty(String name) { return AccessController.doP } in Platform.java to avoid the long lines. Otherwise looks good to me too! best regards, -- daniel On 31/08/2018 19:42, Igor Ignatyev wrote: Alan, Chris, thanks f

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

Igor, > On 31 Aug 2018, at 19:42, Igor Ignatyev wrote: > > Alan, Chris, > > thanks for looking at it, I went w/ the alternative suggested by Chris. that > required a sprinkle of doPrivileged in the testlibrary, but now > Sockets/policy.* files grant the minimal required permissions to the tes

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

On 31/08/2018 19:42, Igor Ignatyev wrote: Alan, Chris, thanks for looking at it, I went w/ the alternative suggested by Chris. that required a sprinkle of doPrivileged in the testlibrary, but now Sockets/policy.* files grant the minimal required permissions to the test code. the incrementa

Re: [12] RFR of JDK-8209832: Refactor jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test

On 04/09/2018 10:26, Amy Lu wrote: Thank you Alan! I updated SetupGetCallerClass: http://cr.openjdk.java.net/~amlu/8209832/webrev.01/ This looks okay to me. -Alan

RE: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

> The change looks fine. We can enhance the name if we want to support .SF > parsing later. > > Please revise your CSR and get it approved first. Hi Max, Thanks ! I adjusted the CSR , please approve : https://bugs.openjdk.java.net/browse/JDK-8207768 Best regards, Matthias > -Original M

StackWalker::getCallerClass throws UnsupportedOperationException

Hi StackWalker::getCallerClass can throw "UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive", depending on how the underlying fetchNextBatch/fill_in_frames splits the stacktrace. This seems to be a result of what was introduced in JDK-8157464. The followin

Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

Hi Brian/Goetz, Yes, that seems sensible. I have created a new webrev with fdlibm compiler option disabled, and mediaLib code fixed: http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. Are we good to go? Thanks Andrew hg exp

[12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1

test/jdk/java/util/Arrays/TimSortStackSize2.java This test was demoted to tier2 due to JDK-8199265 (test fails with OOM). This issue has been fixed (in jdk-11+20) and test has been run (in tier2) without failure happening after that. Let's move it back to tier1. bug: https://bugs.openjdk.jav

Re: [12] RFR of JDK-8209832: Refactor jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test

On 2018/9/4 3:14 PM, Alan Bateman wrote: On 04/09/2018 06:41, Amy Lu wrote: test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh Please review this patch to refactor above shell script test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8209832 webrev: http://cr.openjdk.java.

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Rob, I concur with Chris. completed needs to be volatile and close() needs to set a flag and use offer like cancel(). The condition for testing for closed then becomes that the flag is set and the queue is empty or has EOF as its head. Is there any way this could be tested by a regression te

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Rob, > On 3 Sep 2018, at 22:48, Rob McKenna wrote: > > Hi folks, > > I'd like to get a re-review of this change: > > https://bugs.openjdk.java.net/browse/JDK-8139965 > This issue is closed as `will not fix`. I presume you will re-open it bef

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Rob, Code change looks good to me. Thanks, Vyom On Tuesday 04 September 2018 03:18 AM, Rob McKenna wrote: Hi folks, I'd like to get a re-review of this change: https://bugs.openjdk.java.net/browse/JDK-8139965 http://cr.openjdk.java.net/~robm/8139965/webrev/ In case the original has gon

Re: [12] RFR of JDK-8209832: Refactor jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test

On 04/09/2018 06:41, Amy Lu wrote: test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh Please review this patch to refactor above shell script test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8209832 webrev: http://cr.openjdk.java.net/~amlu/8209832/webrev.00/ This looks ok