Re: [8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Ivan, the JBS bug description is scare on detail. Can you fill it out a bit ? Some examples of the stack trace encountered and links to OpenJDK reviews/discussions will help people who encounter this issue in the future. Regards, Sean. On 02/03/2016 20:20, Martin Buchholz wrote: Reviewed!

Re: [8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Approved for jdk8u-dev (BTW). Regards, Sean. On 03/03/2016 09:04, Seán Coffey wrote: Ivan, the JBS bug description is scare on detail. Can you fill it out a bit ? Some examples of the stack trace encountered and links to OpenJDK reviews/discussions will help people who encounter this issue i

RFR: 8151123 - Collectors.summingDouble/averagingDouble unnecessarily call mapper twice

Hello! Please review and sponsor this small change: https://bugs.openjdk.java.net/browse/JDK-8151123 http://cr.openjdk.java.net/~tvaleev/webrev/8151123/r1/ User-supplied mapper function is unnecessarily called twice on each accumulation event in summingDouble and averagingDouble. This function c

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Hans, On Thu, Mar 3, 2016 at 4:08 AM, Hans Boehm wrote: > > On Wed, Mar 2, 2016 at 12:09 AM, Thomas Stüfe > wrote: > > > > Hi Hans, > > > > thanks for the hint! > > > > But how would I do this for my problem: > > > > Allocate memory, zero it out and then store the pointer into a variable > s

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, > The more I look at this, the more I think that the costs for a > pthread mutex lock are acceptable in this case: we are about to do a > blocking IO operation anyway, which is already flanked by two mutex > locking calls (in startOp and endOp). I doubt that a third mutex call > will be th

RFR [9] 8151140: Replace use of lambda/method ref in jdk.Version constructor

Since 8150163 [1], jdk.Version can now be used earlier in startup, but not always. It was noticed that the use of lambda / method ref in the constructor, in some cases, was the first usage of such, and incurred the initialization costs of the java.lang.invoke infrastructure ( which can take a signi

Re: RFR: 8151123 - Collectors.summingDouble/averagingDouble unnecessarily call mapper twice

> On 3 Mar 2016, at 10:26, Tagir F. Valeev wrote: > > Hello! > > Please review and sponsor this small change: > > https://bugs.openjdk.java.net/browse/JDK-8151123 > http://cr.openjdk.java.net/~tvaleev/webrev/8151123/r1/ > > User-supplied mapper function is unnecessarily called twice on each >

Re: RFR [9] 8151140: Replace use of lambda/method ref in jdk.Version constructor

+1 Paul. > On 3 Mar 2016, at 11:31, Chris Hegarty wrote: > > Since 8150163 [1], jdk.Version can now be used earlier in startup, but not > always. It was noticed that the use of lambda / method ref in the constructor, > in some cases, was the first usage of such, and incurred the initialization

Re: RFR(S): 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' is null, 'step' and 'pred' have parameters

> On 2 Mar 2016, at 20:53, Michael Haupt wrote: > > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150957 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150957/webrev.00/ > > The bug was actually fixed with the push for JDK-8150635. This change adds a

Re: RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

> On 2 Mar 2016, at 20:12, Steve Drach wrote: > > Please review the following fix for JDK-8150679 > > webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ > > issue: https://bugs.openjdk.java.net/browse/JDK-8150679 >

Re: RFR: jsr166 jdk9 integration wave 5

> On 2 Mar 2016, at 21:37, Martin Buchholz wrote: > > Webrevs updated, incorporating changes to tests in my previous message. Looks ok, but i went through rather quickly. java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java — -pool.schedule(keepPoolBusy, 0, Time

Re: RFR(S): 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' is null, 'step' and 'pred' have parameters

Hi Paul, > Am 03.03.2016 um 11:58 schrieb Paul Sandoz : > Minor comment, up to you to accept/reject: you could assert that “w.i” is the > expected value after the loop invocation. thank you. Excellent suggestion, I'll push with that added. Best, Michael -- Dr. Mich

Re: [8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Thank you Martin and Seán! I'll add some info to the bug report with a reproducer code and symptoms. Sincerely yours, Ivan On 03.03.2016 12:07, Seán Coffey wrote: Approved for jdk8u-dev (BTW). Regards, Sean. On 03/03/2016 09:04, Seán Coffey wrote: Ivan, the JBS bug description is scare on

Re: Custom security policy without replacing files in the OpenJDK?

On 03/02/2016 08:45 PM, David Holmes wrote: On 27/02/2016 2:56 AM, Marcus Lagergren wrote: Hi! Is it possible to override lib/security/local_policy on app level without patching jdk distro? i.e. -Duse.this.policy.jar= … or something? Can’t find a way to do it http://docs.oracle.com/javase/8/

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

I’d like to cast a vote for inclusion this fix in jdk9. Probably it has to be done in the original review thread created by Alex: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036463.html http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003036.html but there is no

Re: [DONG] Re: [DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection

Hi all, Could someone please review this patch? Thanks, Yuji 2016-02-09 15:50 GMT+09:00 KUBOTA Yuji : > Hi David, > > Thank you for your advice and cc-ing! > > I do not have any role yet, so I paste my patches as below. > > diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel

Re: RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

Hi, On 2016-03-03 12:26, Paul Sandoz wrote: On 2 Mar 2016, at 20:12, Steve Drach wrote: Please review the following fix for JDK-8150679 webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ Looks OK to me. issue: https://bugs.openj

Re: RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method

comments inlinined ... - Mail original - > De: "Kumar Srinivasan" > À: "core-libs-dev" , "Remi Forax" > > Cc: "SUNDARARAJAN.ATHIJEGANNATHAN" , > "Michael Haupt" > , "Jaroslav Bachor?k" > , "Coleen Phillmore" > , "Stas Smirnov" > , "harsha wardhana b" > > Envoyé: Mercredi 2 Mars 2016

(Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi all, https://bugs.openjdk.java.net/browse/JDK-8150460 thanks to all who took the time to review the first version of this fix! This is the new version: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.02/webrev/ I reworked the fix, trying to add in all the input

Re: RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

> On Mar 3, 2016, at 3:26 AM, Paul Sandoz wrote: > > >> On 2 Mar 2016, at 20:12, Steve Drach wrote: >> >> Please review the following fix for JDK-8150679 >> >> webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ >> >> issue: https:

Match.appendReplacement with StringBuilder

Greetings, It would be nice if java.util.regex.Matcher had a replacement for Matcher appendReplacement(StringBuffer sb, String replacement) StringBuffer appendTail(StringBuffer sb) That took StringBuilder.

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

Hi, Stephen, Roger Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.04/ Regards, Nadeesh On 3/1/2016 12:29 AM, Stephen Colebourne wrote: I'm happy to go back to the spec I proposed before. That spec would determine colons dynamically on

Re: Match.appendReplacement with StringBuilder

On 3/3/16, 10:26 AM, Dave Brosius wrote: Greetings, It would be nice if java.util.regex.Matcher had a replacement for Matcher appendReplacement(StringBuffer sb, String replacement) StringBuffer appendTail(StringBuffer sb) That took StringBuilder. we have added that

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Hi, Roger - Thanks for the comments Made the necessary changes in the spec Please see the updated webrev http://cr.openjdk.java.net/~ntv/8030864/webrev.05/ On 3/3/2016 12:21 AM, nadeesh tv wrote: Hi , Please see the updated webrev http://cr.openjdk.java.net/~ntv/8030864/webrev.03/ Thanks

Re: RFR: jsr166 jdk9 integration wave 5

Committing. On Thu, Mar 3, 2016 at 3:48 AM, Paul Sandoz wrote: > java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java > — > > -pool.schedule(keepPoolBusy, 0, TimeUnit.SECONDS); > +pool.schedule(keepPoolBusy, 0, DAYS); > > It probably does not matter

Re: [DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection

Hi Yuji, An issue has been created to track this issue: JDK-8151212 Flush in RMI TCPChannel createConnection can hang indefinitely Please send the patch and the reproducer in the body of email and I'll attach them to the bug report. Thanks

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

Hi Nadeesh, Looks good. Thanks, Roger On 3/3/2016 1:37 PM, nadeesh tv wrote: Hi, Stephen, Roger Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.04/ Regards, Nadeesh On 3/1/2016 12:29 AM, Stephen Colebourne wrote: I'm happy to go b

JDK 9 RFR of JDK-8151226: Mark UdpTest.java as intermittently failing

Hello, The test java/net/ipv6tests/UdpTest.java has been observed to intermittently fail (JDK-8143998, JDK-8143097). Until these problems are addressed, the test should be marked accordingly. Please review the patch below which marks the test. Thanks, -Joe diff -r a603b1f1d9a1 test/jav

Re: JDK 9 RFR of JDK-8151226: Mark UdpTest.java as intermittently failing

looks ok joe On Mar 3, 2016, at 6:01 PM, joe darcy wrote: > Hello, > > The test > >java/net/ipv6tests/UdpTest.java > > has been observed to intermittently fail (JDK-8143998, JDK-8143097). > > Until these problems are addressed, the test should be marked accordingly. > > Please review the

Re: [DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection

Hi Roger, Thank you for your help! My patch and reproducer are as below. * patch diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java

RFR: Regex exponential backtracking issue

Hi, webrev: http://cr.openjdk.java.net/~sherman/regexBacktracking/webrev/ Backtracking is the powerful and popular feature provided by Java regex engine when the regex pattern contains optional quantifiers or alternations, in which the regex engine can return to the previous saved state (backt

[9] RFR: 8150702: change in javadoc for parseObject for MessageFormat - JDK-8073211

Hello, Please review this small fix for jdk9/dev repo :- Bug: https://bugs.openjdk.java.net/browse/JDK-8150702 Webrev: http://cr.openjdk.java.net/~ntv/vaibhav/8150702/webrev.00/ Reason :- MessageFormat don't throw NullPointer exception if source is null. This condition is explicitly handled in

[PING] RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees

Hi, Ping - any comments or reviews for this bugfix? Thanks Christoph From: Langer, Christoph Sent: Freitag, 26. Februar 2016 16:02 To: core-libs-dev@openjdk.java.net Subject: RFR: JDK-8150704 XALAN: ERROR: 'No more DTM IDs are available' when transforming with lots of temporary result trees Hi