Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

2017-10-23 Thread David Holmes
Hi Peter, Ogata, Are you saying this is correct even if cachedLoader is not volatile? If so then that needs to be clearly documented. Cheers, David On 24/10/2017 3:11 PM, Peter Levart wrote: Hi, I think that what Ogata has in webrev.03 is correct and the reasoning could be as follows: -

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

2017-10-23 Thread Kazunori Ogata
Hi Peter, Thank you for your review and summarizing the change. Regards, Ogata Peter Levart wrote on 2017/10/24 14:11:01: > From: Peter Levart > To: Kazunori Ogata > Cc: Alan Bateman , [email protected] > Date: 2017/10/24 14:11 > Subject: Re: RFR: 8188858: Caching latestUserDe

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

2017-10-23 Thread Peter Levart
Hi, I think that what Ogata has in webrev.03 is correct and the reasoning could be as follows: - each thread writes to field 'cachedLoader' only from its own set of values that are distinct from the sets of values that may be written by any other thread, except null value. - each thread read

Re: RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial

2017-10-23 Thread Joe Wang
Thanks Lance for the super fast review!!! I haven't thought I'd check back today :-) On 10/23/17, 5:44 PM, Lance Andersen wrote: looks fine Joe On Oct 23, 2017, at 8:37 PM, Joe Wang > wrote: Hi, Please review a fix that cleans up [serial] warnings by adding th

Re: [10] RFR: 8189272 & 8189291

2017-10-23 Thread mandy chung
On 10/20/17 5:05 PM, Naoto Sato wrote: Hi Mandy, Thanks for the review. Webrevs updated as suggested: http://cr.openjdk.java.net/~naoto/8189272/webrev.01/ http://cr.openjdk.java.net/~naoto/8189291/webrev.01/ DEFAULT_POLICY in test/jdk/java/util/logging/* tests can be moved to the enclosin

Re: RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial

2017-10-23 Thread Lance Andersen
looks fine Joe > On Oct 23, 2017, at 8:37 PM, Joe Wang wrote: > > Hi, > > Please review a fix that cleans up [serial] warnings by adding the > serialVersionUID. The following tests showed that the serialVersionUID for > the classes in this patch have not changed from JDK 1.4 to JDK 9: > fo

RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial

2017-10-23 Thread Joe Wang
Hi, Please review a fix that cleans up [serial] warnings by adding the serialVersionUID. The following tests showed that the serialVersionUID for the classes in this patch have not changed from JDK 1.4 to JDK 9: for each cls in classes that are missing serialVersionUID for jdk f

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

2017-10-23 Thread Peter Levart
Hi Ogata, Sorry for late reply. You are absolutely right. Good catch! I missed this scenario. The criteria for placing the mark (current Thread) on a cachedLoader must include the check that validates previous value for later restoration which uses the same criteria. Only in such case will on

tzdata2017c is out

2017-10-23 Thread Martin Buchholz
tzdata2017c came out today, and the elves at Google are working hard to incorporate changes in hours or days instead of weeks or quarters. One thing we noticed is that one of the java.time tck tests was broken by tzdata rewrite of history. Here's the fix we're applying (s/1879/1892/g): @@ -941,2

Re: java 9 AKST timezone parsing

2017-10-23 Thread Naoto Sato
https://bugs.openjdk.java.net/browse/JDK-8189784 Naoto On 10/19/17 11:57 AM, Clément Guillaume wrote: I posted it few days ago (and got the id 9051213). I think it's still being reviewed. 2017-10-11 17:11 GMT-07:00 Naoto Sato >: Yes. Please go ahead and fil

Re: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

2017-10-23 Thread Claes Redestad
On 2017-10-23 13:30, Christoph Dreis wrote: I don't think we need the explicit range check here. I thought about that, but decided against the specific ArrayIndexOutOfBoundsException which would be thrown if we omit the explicit check. My reasoning behind that was that the API should not expose

RE: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

2017-10-23 Thread Christoph Dreis
Hey, > > > public Class getParameterType(int index) { > > > if (index < 0 || index > getParameterCount()) { > > > throw new IndexOutOfBoundsException("No parameter found > > > on index " + index); > > > } > > I don't think we need the explicit range check here

RE: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

2017-10-23 Thread Christoph Dreis
Hey Claes, thank you for your comments on my proposal. > > public Class getParameterType(int index) { > > if (index < 0 || index > getParameterCount()) { > > throw new IndexOutOfBoundsException("No parameter found > > on index " + index); > > } > > I don't thi