Re: performance degradation in Array::newInstance on -XX:TieredStopAtLevel=1

Hi Claes, thanks for the explanation, I suspected something like that. I've run into this performance effect while investigating creation of Spring's ConcurrentReferenceHashMap, it turned out that it used Array::newInstance to create array of References stored in a map's Segment: private Refer

[13] RFR 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale.

Hello, Please help review the fix for the test bug java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/ Thanks, Dora

Re: RFR(JDK 13/java.xml) javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match

Hi Joe, The changes and test seem fine! Happy New Year > On Jan 3, 2019, at 6:25 PM, Joe Wang wrote: > > Hi, > > Please review a fix to the impl for the Catalog. The reporter was right, in > the Group case, we failed to update the currently longest match when a match > is found. > > JBS: h

Re: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams

The webrev looks fine to me, too. Unrelated to this change, but something I noticed: test/jdk/java/lang/ProcessBuilder/PipelineTest.java 173 setFileContents(infile, expected); Shouldn't the contents of 'infile' be set to 'input', rather than 'expected'? Thanks, -Brent On 1/3/19 2

RFR(JDK 13/java.xml) javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match

Hi, Please review a fix to the impl for the Catalog. The reporter was right, in the Group case, we failed to update the currently longest match when a match is found. JBS: https://bugs.openjdk.java.net/browse/JDK-8215330 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8215330/webrev/ Thanks

Re: Class.getDeclaredMethods() is returning inherited methods

Hi Roger, On 4/01/2019 12:22 am, Roger Riggs wrote: Hi, With a link to the explanation added to the issue, I think it can be closed as not-an-issue. Do you think the Class.getDeclared* method specs should be updated to reflect (pardon the pun) that synthetic methods/constructors will be in

Re: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams

Speaking of, you might want to change the copyright years to 2019. :) -Brent On 1/3/19 2:32 PM, Roger Riggs wrote: Happy New Year On 01/03/2019 05:27 PM, Lance Andersen wrote: Happy New Year On Jan 3, 2019, at 3:47 PM, Roger Riggs Happy New Year!

Re: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams

Thanks Lance, Happy New Year On 01/03/2019 05:27 PM, Lance Andersen wrote: Hi Roger, The changes look reasonable to me. Happy New Year On Jan 3, 2019, at 3:47 PM, Roger Riggs > wrote: Please review a bug fix for the ProcessBuilder startPipeline test and Win

Re: 8216134 (process) ProcessBuilder startPipeline does not hide piped streams

Hi Roger, The changes look reasonable to me. Happy New Year > On Jan 3, 2019, at 3:47 PM, Roger Riggs wrote: > > Please review a bug fix for the ProcessBuilder startPipeline test and Windows > implementation. > The test failed to check that Process.getInputStream returned the null stream > fo

Re: UnicodeDecoder U+FFFE handling

Sounds reasonable. Filed the following issue: https://bugs.openjdk.java.net/browse/JDK-8216140 Naoto On 1/1/19 10:06 PM, li.ji...@oracle.com wrote: Sounds this request is reasonable since Unicode 7: do not consider the U+FFFE in the middle of stream as malformed. FAQ about private use charac

8216134 (process) ProcessBuilder startPipeline does not hide piped streams

Please review a bug fix for the ProcessBuilder startPipeline test and Windows implementation. The test failed to check that Process.getInputStream returned the null stream for all but the last process in the pipeline.  When the test was fixed it failed on Windows. The Windows ProcessImpl did not

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi Martin, can we please finish this review? On 12/19/18 6:32 PM, Michal Vala wrote: On 12/19/18 4:15 PM, Martin Buchholz wrote: On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: Hi Martin, It is also useful and conventional to print the seed of the random so that if necessary it can be

Re: RFR: 8182992 Typo in DatagramPacket constructor API doc

Hi Roger, Please see below. I am not sure how much review the javadocs have gotten for the com/sun/rowset/internal classes > > > > JDK-8215911 Various Typos in SQL Method Documentation > https://bugs.openjdk.java.net/browse/JDK-8215911 >

RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec

Please review the fix for bug [1] at [2]. Basically the constants API introduced as part of JEP-334 [3] were accepting descriptors and class names not allowed by the spec. This implementation fixes several issues found by TCK tests on JEP-334, Thanks, Vicente [1] https://bugs.openjdk.java.net

Re: RFR: 8182992 Typo in DatagramPacket constructor API doc

Hi Roger, On 03/01/2019 17:51, Roger Calnan wrote: + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will I believe there's still a space missing after `large` in the line above. best regards, -- daniel

Re: RFR: 8182992 Typo in DatagramPacket constructor API doc

Looks fine to me. We can update the bug summary to make it more general to affected classes. I can help sponsor this change if required. regards, Sean. On 03/01/2019 16:51, Roger Calnan wrote: I was looking at the fix for: https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in Data

Re: [PATCH] Remove unused variables in io_util_md.c handleLseek

Hi Andrew, Created Jira 8216067 and will sponsor the patch. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-luo-patch-8216067-1/ Thanks and Happy New Year, Roger On 12/21/2018 10:19 PM, Andrew Luo wrote: While looking through this code debugging another issue I noticed there were some ext

[12] RFR: 8215303: Allowing additional currency code points from later Unicode updates

Hello, Please review the fix to the following issue (and its approved CSR): https://bugs.openjdk.java.net/browse/JDK-8215303 https://bugs.openjdk.java.net/browse/JDK-8215305 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8215303/webrev.00/ This is a spec only modifica

RFR: 8182992 Typo in DatagramPacket constructor API doc

I was looking at the fix for: https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in DatagramPacket constructor API doc and searched around for other similar issues. I found: 4 in networking 2 in SQL 2 in client libs all of which are cases of missing spaces. I will ask for review o

Re: Class.getDeclaredMethods() is returning inherited methods

Hi, With a link to the explanation added to the issue, I think it can be closed as not-an-issue. Roger On 01/03/2019 07:19 AM, Steve Groeger wrote: Hi Peter, Thanks again for your explanation. It was the public vs. non-public part that I had missed and I was getting confused thinking it w

Re: Class.getDeclaredMethods() is returning inherited methods

Hi Peter, Thanks again for your explanation. It was the public vs. non-public part that I had missed and I was getting confused thinking it was related to abstract vs. non-abstract classes. The generation of the synthetic methods and why the methods are shown via the getDeclaredMethods() make

Re: Class.getDeclaredMethods() is returning inherited methods

Hi Steve, The difference you observe between variants of class A is not about the "abstract" vs. non-"abstract" but about "public" vs. non-"public"... Your variants of class A are: public class A {     public void foo() {} } vs. abstract class A {     public void foo() {} } The 1st is pub

RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Thank you very much, David, for helping file the bug in system. Hi, Core Libraries Group, I am not quite clear who owns jdk.pack/share/native/common-unpack/zip.cpp (at jdk/jdk for example). Could anyone please help? The issue covered in this thread is a simple but a generic concern to all bran

JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ??

Hi, I'm currently investigating bug JDK-8215626 and have discovered the problem is in the Pattern interpretation of the [^..&&..] negation when applied to "intersected" expressions. So I have simplified the bug example to a more extreme and obvious example: Input string: "1234 ABCDEFG !$%^&

Re: Class.getDeclaredMethods() is returning inherited methods

Hi Peter, Thank you very much for your detailed and very informative explanation. I have one more question for clarification. If I have the following code: abstract class A { public void foo() {} } import java.lang.reflect.*; public class B extends A { public static void main(String