Re: RFR: JDK-8197594: String#repeat

Hi Jim, src/java.base/share/classes/java/lang/String.java 2972 * This method may be used to create space padding for 2973 * formatting text or zero padding for formatting numbers. 2974 * @param count number of times to repeat 2975 * @return A string composed of this string

Re: Reactive Streams utility API

Hi all, We've put together a simple proposal for this. Please read the README for an introduction to this proposal. https://github.com/lightbend/reactive-streams-utils Regards, James On 22 February 2018 at 11:47, James Roper wrote: > Hi all, > > This is an email to give

Re: RFR: JDK-8197594: String#repeat

Thanks Stuart. RE apinote, I was trying to follow the pattern of other older method comments (Roman-style.) Comments/Javadoc in most of these older classes are a mix of styles. Question: if you update/clean-up a method in an older class, should you bring the comment/Javadoc up-to-date as well?

Re: RFR: JDK-8197594: String#repeat

Thanks Paul. Sent from my iPhone > On Feb 28, 2018, at 10:13 PM, Paul Sandoz wrote: > > Hi Jim, > > Looks good. I like the power of 2 copying. > > > 2978 * @throws IllegalArgumentException if the {@code count} is > 2979 * negative. > 2980 */

Re: RFR: JDK-8197594: String#repeat

Hi Jim, Looks good. I like the power of 2 copying. 2978 * @throws IllegalArgumentException if the {@code count} is 2979 * negative. 2980 */ 2981 public String repeat(int count) { Missing @since11 on the method. Like Stuart suggests, turn the explanatory text into

[JDK 11] RFR 8198821: fix test methods access for test java/text/Normalizer/NormalizerAPITest.java

Please review the minor change for test java/text/Normalizer/NormalizerAPITest.java, thanks Added public access modifier to all “Test_" methods so they can be recognized as test method correctly by util class bug: https://bugs.openjdk.java.net/browse/JDK-8198821

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 1:22 PM, Lance Andersen wrote: > >> >> On Feb 28, 2018, at 2:20 PM, Lance Andersen > > wrote: >> >> Hi Paul, >> >> Thank you for the review. >>> On Feb 28, 2018, at 1:40 PM, Paul

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

I was surprised to learn that junit has a magic assertEquals specifically for Object[] assertEquals(Object[], Object[]) but that is obviously a bad idea and junit eventually deprecated it. https://junit.org/junit4/javadoc/4.12/org/junit/Assert.html#assertEquals(java.lang.Object[],

Re: RFR: Here are some URLClassPath patches

OK, that was weird... All I did for testing was follow // This section should be uncommented if 8026517 is fixed. but ... 8026517 is marked fixed! So switching to ArrayDeque accidentally fixed 8026517 for real?! 8198810: URLClassLoader does not specify behavior when URL array contains null

Re: RFR: JDK-8197594: String#repeat

Hi Jim, Implementation looks good. I'd suggest a couple small editorial changes to the spec: 2966 /** 2967 * Returns a string whose value is the concatenation of this 2968 * string repeated {@code count} times. 2969 * 2970 * If count or length is zero then the empty

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Hi Lance, I'd prefer if src/java.sql/share/classes/javax/transaction/xa/package.html was replaced by a package-info.java files as opposed to another package.html file in the new module. Thanks, -Joe On 2/28/2018 1:22 PM, Lance Andersen wrote: On Feb 28, 2018, at 2:20 PM, Lance Andersen

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 2018-02-28 19:25, Lance Andersen wrote: Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 2:20 PM, Lance Andersen wrote: > > Hi Paul, > > Thank you for the review. >> On Feb 28, 2018, at 1:40 PM, Paul Sandoz > > wrote: >> >> Compatible module refactoring in action! >> >>

RFR 8196298 Add null Reader and Writer

Hi every boy that reviewed I tried to incorporate all feedback I received so far and updated the webrev accordingly: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 -Patrick

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 2:43 PM, Alan Bateman wrote: > > On 28/02/2018 18:25, Lance Andersen wrote: >> Hi all, >> >> This RFR request moves the javax.transaction.xa package out of the java.sql >> module and into its own module java.transaction.xa. One of the motivators

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 28/02/2018 18:25, Lance Andersen wrote: Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Hi Paul, Thank you for the review. > On Feb 28, 2018, at 1:40 PM, Paul Sandoz wrote: > > Compatible module refactoring in action! > > Looks good, one comment: > > test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java > > This is not a valid Java source file

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Compatible module refactoring in action! Looks good, one comment: test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? Paul. > On Feb 28, 2018, at 10:25 AM, Lance Andersen

RFR JDK-8197533 move javax.transaction.xa into its own module

Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa package will be subsumed by Java SE. There

Re: RFR: 8193660 Check SOURCE line in "release" file for closedjdk

On 02/28/18 11:58 AM, Alan Bateman wrote: On 28/02/2018 16:57, Randy Crihfield wrote: poke poke can someone please review? Thanks The `release` is a properties file so I assume you can simplify the test by using Properties.load and then testing if the "SOURCE" key is present and whether

Re: RFR: Here are some URLClassPath patches

On 28/02/2018 18:04, Martin Buchholz wrote: : Too bad the URL[] argument is not consistently the last one, else one could  convert them all to varargs. Varargs-friendliness seems like an independent change. Yes, completely separate issue and one that is already tracked:

Re: RFR: Here are some URLClassPath patches

On Wed, Feb 28, 2018 at 6:17 AM, Alan Bateman wrote: > On 28/02/2018 03:02, Martin Buchholz wrote: > > I should probably do more testing than usual when touching classloading... > > We have a jdi test that does this (hg blame finds duke as only author): > > public

Re: RFR: 8193660 Check SOURCE line in "release" file for closedjdk

On 28/02/2018 16:57, Randy Crihfield wrote: poke poke can someone please review?  Thanks The `release` is a properties file so I assume you can simplify the test by using Properties.load and then testing if the "SOURCE" key is present and whether it has the expected value. -Alan.

Re: RFR: 8193660 Check SOURCE line in "release" file for closedjdk

poke poke can someone please review? Thanks Randy On 02/15/18 12:25 PM, Randy Crihfield wrote: I need to revise the resource file test created for JDK-8192837 The new bug is https://bugs.openjdk.java.net/browse/JDK-8193660 The webrev is located at

RFR: JDK-8197594: String#repeat

Introduction of a new instance method String::repeat to allow an efficient and concise approach for generating repeated character sequences as strings. Performance information in JBS. Thank you. Cheers, — Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8197594

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

+1; looks good On 2/27/2018 3:15 PM, Xueming Shen wrote: +1 On 2/27/18, 11:37 AM, Joe Wang wrote: Hi Sherman and all, Thanks for the further reviews! Here's the latest webrev with boundary checks in StringLatin1/StringUTF16: JBS: https://bugs.openjdk.java.net/browse/JDK-8137326 webrev:

RFR 8198697: Simplify platform encoding initialization tweak

Hi, In an effort to untangle some of the issues with property initialization I was looking at the platform encoding initialization and found a simplification. Currently, the initialization occurs as a side effect of the first call to JNU_NewStringPlatform and involves a upcall to get

Re: RFR: 8198831: Lazy initialization of ValueConversions MethodHandles

On 2018-02-28 14:48, Aleksey Shipilev wrote: On 02/28/2018 02:16 PM, Claes Redestad wrote: this patch makes the lookup of various MH in sun.invoke.util.ValueConversions lazy, realizing a tiny startup optimization to various apps. Webrev: http://cr.openjdk.java.net/~redestad/8198831/jdk.00/

Re: RFR: Here are some URLClassPath patches

On 28/02/2018 03:02, Martin Buchholz wrote: I should probably do more testing than usual when touching classloading... We have a jdi test that does this (hg blame finds duke as only author):     public static ClassLoader classLoaderValue;     {         try {             urls[0] = new URL("hi

Re: RFR: 8198831: Lazy initialization of ValueConversions MethodHandles

On 02/28/2018 02:16 PM, Claes Redestad wrote: > this patch makes the lookup of various MH in sun.invoke.util.ValueConversions > lazy, realizing a tiny > startup optimization to various apps. > > Webrev: http://cr.openjdk.java.net/~redestad/8198831/jdk.00/ Looks good to me. -Aleksey

RFR: 8198831: Lazy initialization of ValueConversions MethodHandles

Hi, this patch makes the lookup of various MH in sun.invoke.util.ValueConversions lazy, realizing a tiny startup optimization to various apps. Webrev: http://cr.openjdk.java.net/~redestad/8198831/jdk.00/ Bug:    https://bugs.openjdk.java.net/browse/JDK-8198831 Thanks! /Claes

sun.rmi.transport.tcp.responseTimeout ignored

Hi All, We started a new Java standalone application with OpenJDK Runtime Environment (build 1.8.0_161-b14). This application has a network problem to connect to a RMI service and the application threads remained in hang status. We tried to apply the parameter

Re: [JDK 11] Problem list tools/jimage/JImageExtractTest.java for macosx-all

On 28/02/2018 6:23 PM, Alan Bateman wrote: On 28/02/2018 08:53, Amy Lu wrote: Please review the patch to problem list tools/jimage/JImageExtractTest.java for macosx-all. This test fails frequently (observed at Mac) and should be problem listed before JDK-8198819 fixed. bug:

Re: [JDK 11] Problem list tools/jimage/JImageExtractTest.java for macosx-all

On 28/02/2018 08:53, Amy Lu wrote: Please review the patch to problem list tools/jimage/JImageExtractTest.java for macosx-all. This test fails frequently (observed at Mac) and should be problem listed before JDK-8198819 fixed. bug: https://bugs.openjdk.java.net/browse/JDK-8198820 webrev:

[JDK 11] Problem list tools/jimage/JImageExtractTest.java for macosx-all

Please review the patch to problem list tools/jimage/JImageExtractTest.java for macosx-all. This test fails frequently (observed at Mac) and should be problem listed before JDK-8198819 fixed. bug: https://bugs.openjdk.java.net/browse/JDK-8198820 webrev: