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

2016-10-07 Thread Anubhav Meena
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 d

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

2016-10-07 Thread Jonathan Bluett-Duncan
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 Oc

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

2016-10-07 Thread Tim Bell
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 thr

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

2016-10-07 Thread Erik Joelsson
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.

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

2016-10-07 Thread Tim Bell
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

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

2016-10-07 Thread Joe Wang
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 (JAXP) 8139584: XMLStreamWriterImpl does not write 'standalone' property

2016-10-07 Thread Lance Andersen
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: http://cr.openjdk.java.net/~joehw/jdk9/8139584/webrev/ > > Thanks, > Joe

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

2016-10-07 Thread Stuart Marks
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 wa

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

2016-10-07 Thread Joe Wang
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: https://bugs.openjdk.java.net/browse/JDK-8139584 webr

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

2016-10-07 Thread Paul Sandoz
> 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. > > The or() method is new i

Re: RFR 8151486 : Class.forName causes memory leak

2016-10-07 Thread Brent Christian
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 8151486 : Class.forName causes memory leak

2016-10-07 Thread Mandy Chung
> 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 be cleared. > > There's also

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

2016-10-07 Thread 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. :-) The theoretical answer is that in this context, "? extends P" means "some subtype of P

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

2016-10-07 Thread Stefan Zobel
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. :-) > > The theoretical answe

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

2016-10-07 Thread Michael Nascimento
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 : > > > > > > On 10/7/16 11:23 AM, Paul Sandoz wrote: > >>>

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

2016-10-07 Thread Paul Sandoz
> 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. :-) > I thought as much

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

2016-10-07 Thread Stefan Zobel
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 = Optional.empty(); Func

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

2016-10-07 Thread Andrej Golovnin
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: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-10-07 Thread Patrick Reinhart
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. > > Thank you all for yo

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

2016-10-07 Thread Stuart Marks
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(s): 8152617 add missing wildcards to Optional or() and flatMap()

2016-10-07 Thread Stuart Marks
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 easier to digest. But tha

Re: RFR: 8159855: Create an SPI for tools

2016-10-07 Thread Jonathan Gibbons
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 p

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

2016-10-07 Thread Xueming Shen
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 ints.

Re: RFR: 8159855: Create an SPI for tools

2016-10-07 Thread Mandy Chung
> 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: http://cr.openjdk.java.net/~jjg/8159855/webrev.05/ Looks

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

2016-10-07 Thread Stefan Zobel
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 sta

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

2016-10-07 Thread Remi Forax
- 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 > flatMap() > On 10/7/16 11:23 AM, Paul Sandoz wrote: >>>flatMap(Function> mapper) >> >

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

2016-10-07 Thread Naoto Sato
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 10/7/16

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

2016-10-07 Thread Xueming Shen
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 IllegalArgumentExc

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

2016-10-07 Thread Naoto Sato
+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 @thr

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

2016-10-07 Thread Stuart Marks
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