Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

On 10/7/16 3:12 PM, Stefan Zobel wrote: ... After having looked at lots of generic APIs, it seems to me that a style has emerged where wildcards are used whenever possible, and type parameters are used only when necessary, ... Yes, I'm familiar with that kind of reasoning (I think Josh Bloch

Re: RFR JDK-8166261: Scanner.nextInt(int) (and similar methods) throws PatternSyntaxException

+1 Naoto On 10/7/16 4:08 PM, Xueming Shen wrote: On 10/07/2016 03:52 PM, Naoto Sato wrote: The test case now looks good. Using biconsumer makes it more readable. I see the additional paragraph with regard to IllegalArgumentException in each method description, however, it contradicts the

Re: RFR JDK-8166261: Scanner.nextInt(int) (and similar methods) throws PatternSyntaxException

On 10/07/2016 03:52 PM, Naoto Sato wrote: The test case now looks good. Using biconsumer makes it more readable. I see the additional paragraph with regard to IllegalArgumentException in each method description, however, it contradicts the @throws clause. Need to add @throws

Re: RFR JDK-8166261: Scanner.nextInt(int) (and similar methods) throws PatternSyntaxException

The test case now looks good. Using biconsumer makes it more readable. I see the additional paragraph with regard to IllegalArgumentException in each method description, however, it contradicts the @throws clause. Need to add @throws IllegalArgumentException for each method? Naoto On

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

- Mail original - > De: "Stuart Marks" > À: "Paul Sandoz" > Cc: "core-libs-dev" > Envoyé: Vendredi 7 Octobre 2016 21:22:09 > Objet: Re: RFR(s): 8152617 add missing wildcards to Optional or() and >

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

Hi Stuart, thanks for explaining. > ... After having looked at lots of generic APIs, it seems to me that a > style has emerged where wildcards are used whenever possible, and type > parameters are used only when necessary, ... Yes, I'm familiar with that kind of reasoning (I think Josh Bloch

Re: RFR: 8159855: Create an SPI for tools

> On Oct 7, 2016, at 2:40 PM, Jonathan Gibbons > wrote: > > Updated webrev with feedback from comments: > > * use doPrivileged within ToolProvider.findFIrst (includes adding new test) > * improve whitespace in doc comments > > Webrev:

Re: RFR JDK-8166261: Scanner.nextInt(int) (and similar methods) throws PatternSyntaxException

thanks! updated, with biconsumer as well. http://cr.openjdk.java.net/~sherman/8166261/webrev/ On 10/05/2016 10:25 AM, Naoto Sato wrote: Looks good to me. The test case could use IntStream.rangeClosed(Character.MIN_RADIX, Character.MAX_RADIX) for the good radixes, instead of hard coding

Re: RFR: 8159855: Create an SPI for tools

Updated webrev with feedback from comments: * use doPrivileged within ToolProvider.findFIrst (includes adding new test) * improve whitespace in doc comments Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.05/ -- Jon On 10/04/2016 09:19 PM, Mandy Chung wrote: This SPI is useful and

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

On 10/7/16 12:40 PM, Stefan Zobel wrote: What's wrong with the alternative "additional bounded type parameter" approach? Couldn't we also get by with something like Optional flatMap(Function> mapper) and Optional or(Supplier supplier) Personally, I find that much

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

On 10/7/16 1:09 PM, Andrej Golovnin wrote: 267 public Optional flatMap(Function> mapper) I think there should be a space between “public” and “”. Sure, I'll add this. There's also a space missing at a similar spot at the map() declaration; I'll fix that too. thanks s'marks

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Here is the latest webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.02 -Patrick > Am 07.10.2016 um 12:00 schrieb Jonathan Bluett-Duncan > : > > Hi all, > > Sorry for the delayed response, I've been busy lately with university and > other things.

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

Hi Stuart, > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8152617/webrev.0/ 267 public Optional flatMap(Function> mapper) I think there should be a space between “public” and “”. Best regards, Andrej Golovnin

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

2016-10-07 21:42 GMT+02:00 Michael Nascimento : > Doesn't work, as Stuart has noted (s'marks, as far as I know your > explanation is 100% correct). Nested generics == pain :-( Hi Michael, sorry for being obtrusive. What exactly doesn't work? Stuart's example Optional oi =

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

> On 7 Oct 2016, at 12:22, Stuart Marks wrote: > > > > On 10/7/16 11:23 AM, Paul Sandoz wrote: >>> flatMap(Function> mapper) >> >> Optional is final so why do you need to express “? extends Optional” ? > > The short answer is, it doesn't work if you don't have it.

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

Doesn't work, as Stuart has noted (s'marks, as far as I know your explanation is 100% correct). Nested generics == pain :-( Regards, Michael On Fri, Oct 7, 2016 at 4:40 PM, Stefan Zobel wrote: > 2016-10-07 21:22 GMT+02:00 Stuart Marks : > > > > >

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

2016-10-07 21:22 GMT+02:00 Stuart Marks : > > > On 10/7/16 11:23 AM, Paul Sandoz wrote: >>> >>>flatMap(Function> mapper) >> >> >> Optional is final so why do you need to express “? extends Optional” ? > > > The short answer is, it doesn't work if you don't have it. :-)

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

On 10/7/16 11:23 AM, Paul Sandoz wrote: flatMap(Function> mapper) Optional is final so why do you need to express “? extends Optional” ? The short answer is, it doesn't work if you don't have it. :-) The theoretical answer is that in this context, "? extends P" means "some subtype of

Re: RFR 8151486 : Class.forName causes memory leak

> On Oct 7, 2016, at 11:25 AM, Brent Christian > wrote: > > On 10/5/16 4:43 PM, David Holmes wrote: >>> Okay but this will still affect the lifecycle of the PDs because without the strong reference in L, those weak references in the VM will quickly

Re: RFR 8151486 : Class.forName causes memory leak

On 10/5/16 4:43 PM, David Holmes wrote: Okay but this will still affect the lifecycle of the PDs because without the strong reference in L, those weak references in the VM will quickly be cleared. There's also a strong reference held by the Class object itself (on the VM side [1]). Thanks

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

> On 7 Oct 2016, at 10:20, Stuart Marks wrote: > > Hi all, > > Please review this small API adjustment to Optional.or and flatMap to add > wildcards. This provides a bit more flexibility to callers about the types of > functions they can provide to these methods. >

Re: RFR (JAXP) 8139584: XMLStreamWriterImpl does not write 'standalone' property

Thanks Lance! On 10/7/16, 10:07 AM, Lance Andersen wrote: Hi Joe, Looks fine Best Lance On Oct 7, 2016, at 12:10 PM, Joe Wang > wrote: Hi, Please review a fix for declaring the 'standalone' attribute. JBS:

RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

Hi all, Please review this small API adjustment to Optional.or and flatMap to add wildcards. This provides a bit more flexibility to callers about the types of functions they can provide to these methods. The or() method is new in 9 so there is no compatibility issue. The flatMap() method

Re: RFR (JAXP) 8139584: XMLStreamWriterImpl does not write 'standalone' property

Hi Joe, Looks fine Best Lance > On Oct 7, 2016, at 12:10 PM, Joe Wang wrote: > > Hi, > > Please review a fix for declaring the 'standalone' attribute. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8139584 > webrev:

RFR (JAXP) 8139584: XMLStreamWriterImpl does not write 'standalone' property

Hi, Please review a fix for declaring the 'standalone' attribute. JBS: https://bugs.openjdk.java.net/browse/JDK-8139584 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139584/webrev/ Thanks, Joe

Re: RFR: JDK-8166648,,jib make run-test for langtools results in intermittent failures on windows-x86

Again with the review link .. see below: On 10/07/16 06:40, Tim Bell wrote: Hello The change of HotSpot runtimes on 32-bit Windows [1] has been a source of langtools test failures due to memory space exhaustion. On our Windows build/test clients, the combination of the C2 runtime and parallel

Re: RFR: JDK-8166648,,jib make run-test for langtools results in intermittent failures on windows-x86

Hello Tim, Assuming this is the webrev: http://cr.openjdk.java.net/~tbell/8166648/webrev/ It looks ok to me. /Erik On 2016-10-07 15:40, Tim Bell wrote: Hello The change of HotSpot runtimes on 32-bit Windows [1] has been a source of langtools test failures due to memory space exhaustion.

RFR: JDK-8166648,,jib make run-test for langtools results in intermittent failures on windows-x86

Hello The change of HotSpot runtimes on 32-bit Windows [1] has been a source of langtools test failures due to memory space exhaustion. On our Windows build/test clients, the combination of the C2 runtime and parallel GC causes about 20 extra threads to be started in each VM. These added

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi all, Sorry for the delayed response, I've been busy lately with university and other things. Thank you all for your comments. I'll leave the DateTimeFormatter comment in, as you requested Stephen and Roger, and I'll work again with Patrick as soon as I'm ready. Kind regards, Jonathan On 6

RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Hi all, Please review. Bug Id : https://bugs.openjdk.java.net/browse/JDK-8163330 Issue: The HijrahDate class incorrectly calculates the aligned-day-of-week field. It based the calculation on the day-of-week, when it should be based on the