RFR 8201348, ProblemList update for bugid associated with SSLSocketParametersTest.sh

Hi,     please review a minor change on the associated bug id in ProblemList.txt. Bug:     https://bugs.openjdk.java.net/browse/JDK-8201348 Patch: diff -r f088ec60bed5 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt  Mon Apr 09 10:39:29 2018 -0700 +++ b/test/jdk/ProblemList.txt 

RE: RFR: 8184692: add Pattern.asMatchPredicate

Thanks Paul / Roger for the inputs. I have updated the javadoc based on the inputs. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 . Please review. Regards Vivek -Original Message- From: Paul Sandoz Sent: Monday, April 09, 2018 9:25 PM To: Roger Riggs

Re: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use

On 10/04/2018 3:09 AM, Roger Riggs wrote: Hi Hamlin, Hi Roger, Thank you for review. Great, the new busy port algorithm looks better. The port assigned will always be one that was available and is now busy to prevent the registry creation. As expected, there is a small window  between

Re: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

Thanks, Erik. Modified GensrcCLDR.gmk as suggested: http://cr.openjdk.java.net/~naoto/8189784/webrev.03/ Naoto On 4/9/18 4:15 PM, Erik Joelsson wrote: Hello Naoto, Looks good, just a style issue. When breaking a recipe line, please add 4 additional spaces (after the tab) for continuation

Re: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

Hello Naoto, Looks good, just a style issue. When breaking a recipe line, please add 4 additional spaces (after the tab) for continuation indent [1]. In this case I would also advocate breaking the line sooner to make side by side comparisons easier in the future. /Erik [1]

Re: Future.get(Duration)?

https://bugs.openjdk.java.net/browse/JDK-8201344 On Mon, Apr 9, 2018 at 3:49 PM, Steven Schlansker < stevenschlans...@gmail.com> wrote: > Hi core-libs-dev, > > Future.get(int, TimeUnit) is great, it allows you to put a timeout. > > Duration is great, it's a common way to cart a duration around,

Future.get(Duration)?

Hi core-libs-dev, Future.get(int, TimeUnit) is great, it allows you to put a timeout. Duration is great, it's a common way to cart a duration around, and some frameworks can parse it for you, say you have an injector (Spring in this case) that can handle: @Value("my-timeout:PT10s") Duration

Re: RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup

> On Apr 6, 2018, at 10:32 PM, John Rose wrote: > > Reviewed; it's good. > Thanks. > The javadoc text doesn't need to predict the future; it just needs to document > the present specification. So the sentence that begins "This constraint > allows for > the future

Re: RFR: jsr166 jdk integration 2018-04

On Mon, Apr 9, 2018 at 12:58 PM, Paul Sandoz wrote: > > Minor typo: “even if array” -> “even if the array” > > typo fixed

[11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8189784 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8189784/webrev.02/ There were two causes of the issue. One was that j.t.f.ZoneName contained hard coded mappings

Re: RFR: jsr166 jdk integration 2018-04

Looks good. ForkJoinPool.java — 356 * readers must tolerate null slots. Worker queues are at odd 357 * indices. Shared (submission) queues are at even indices, up to 358 * a maximum of 64 slots, to limit growth even if array needs to 359 * expand to add more workers.

Re: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use

Hi Hamlin, Great, the new busy port algorithm looks better. The port assigned will always be one that was available and is now busy to prevent the registry creation. As expected, there is a small window  between the (try-with-finally) close of the server socket channel and the 2nd createReg. 

Re: RFR: Export InitializeEncoding for JVM access

Hi Andrew, ok,  it turns out the prototype in jni_util.h also needs to be updated to be consistent for Windows and Solaris. And no surprise, there are no test failures. I put an updated webrev in:   http://cr.openjdk.java.net/~rriggs/webrev-encoding-8201246/ If there are no more comments,

Re: RFR: 8184692: add Pattern.asMatchPredicate

> On Apr 9, 2018, at 9:17 AM, Xueming Shen wrote: > > > Paul, > > I don't recall any particular reason why we did Predicate > asPredicate() instead > of Predicate asPredicate() back 1.8? mutability? > Hmm… me neither i would like to think it was not an oversight

Re: RFR: 8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap

Thanks, Claes. I like very much how you've been reducing java startup every release, but ... I'm bothered by the small but eternal overhead of the INSTANCE fields ... It looks like the UTF_16* charsets don't need INSTANCE fields since they will not be referenced anywhere else in java.base - can

Re: RFR: 8184692: add Pattern.asMatchPredicate

Paul, I don't recall any particular reason why we did Predicate asPredicate() instead of Predicate asPredicate() back 1.8? mutability? sherman On 4/9/18, 8:41 AM, Roger Riggs wrote: Hi Vivek, As with Pattern.asPredicate the first sentence can be improved. Creates a predicate that

Re: RFR: 8184692: add Pattern.asMatchPredicate

> On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: > > Hi Vivek, > > As with Pattern.asPredicate the first sentence can be improved. > > Creates a predicate that tests if this pattern matches the entire region. > The region of what? region is clear from the context

Re: RFR: 8184692: add Pattern.asMatchPredicate

Hi Vivek, As with Pattern.asPredicate the first sentence can be improved. Creates a predicate that tests if this pattern matches the entire region. 5833: As with the original issue, perhaps adding the word 'whole' or 'entire' will make it clearer that the pattern must match then entire

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On 09/04/2018 11:26, Peter Levart wrote: If adding a field to Thread class is a concern, I can modify this to use a special ThreadLocal instance to keep registered callback(s) per thread. Thanks for the prototype, that is along the lines of what I was thinking. I also think it would be good

RFR: 8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap

Hi, JDK-8200310 cleaned up java.nio.charset.StandardCharsets to not use Charset.forName, but also removed the optimization to have unconditionally loaded charsets set up static INSTANCE constants, which means that many systems the java.nio.charset.StandardCharsets will be initialized in

Re: RFR: Export InitializeEncoding for JVM access

Thanks for the feedback Roger, Yes, exporting the InitializeEncoding entry point would make sense, keeping it consistent with Canonicalize(). I have attached the new patch below: Many thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On 04/09/18 12:21, Peter Levart wrote: On 04/09/18 10:33, David Holmes wrote: After thread exits, ThreadLocal values associated with it are no longer reachable from its Thread object. The problem Tony faces is that by the time this happens, direct ByteBuffer's that were cached using such

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On 04/09/18 10:33, David Holmes wrote: After thread exits, ThreadLocal values associated with it are no longer reachable from its Thread object. The problem Tony faces is that by the time this happens, direct ByteBuffer's that were cached using such ThreadLocal value, are already moved to

Re: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order

Ping. -Aleksey On 04/05/2018 05:33 PM, Aleksey Shipilev wrote: > Hi, > > Please review this jdk10 backport. > > Original JDK 11 bug: > https://bugs.openjdk.java.net/browse/JDK-8194554 > > Original JDK 11 fix: > http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 > > Please note the

RE: RFR: 8184692: add Pattern.asMatchPredicate

Hi, Please find the updated webrev after incorporating Paul's comments. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . Regards Vivek -Original Message- From: Paul Sandoz

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

Hi Peter, On 9/04/2018 5:50 PM, Peter Levart wrote: On 04/09/18 08:25, David Holmes wrote: On 7/04/2018 3:11 AM, Tony Printezis wrote: — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote: On Fri,

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On 04/09/18 08:25, David Holmes wrote: On 7/04/2018 3:11 AM, Tony Printezis wrote: — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote: On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On 7/04/2018 3:11 AM, Tony Printezis wrote: — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote: On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote: ThreadLocal clearing