Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Updated on the busy-loops, also removed the unnecessary statics, here comes the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.04/ Thanks, Amy On 7/12/16 2:33 PM, David Holmes wrote: Hi Amy, On 12/07/2016 3:28 PM, Amy Lu wrote: Please help to review the updated webrev, gett

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

On 7/12/16 2:17 PM, Martin Buchholz wrote: Amy, sorry you have so many picky reviewers! My lucky ;-) Additional checking for ThreadDeath may good, but with the thinking that both group.stop() and thread.stop() are deprecated (since 1.2), I don't want to introduce new testcase, but focus on "f

Re: --dry-run description enhancement

> On Jul 12, 2016, at 2:00 PM, Paul Benedict wrote: > > Mandy, perhaps there is a JVM technicality here I'm unfamiliar with. My > understanding of loading a class has always been that it's coupled with > running its static initializers. Loading, linking, and initializing are separate parts sp

RFR: 8159684: (tz) Support tzdata2016f

Hi all, Please review the latest TZDATA integration (tzdata2016f) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8159684 Webrev: http://cr.openjdk.java.net/~rpatil/8159684/webrev.00/ All the TimeZone related tests are passed after this integration. Regards, Ramanand.

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

This looks fine to me. Thanks, David On 12/07/2016 5:11 PM, Amy Lu wrote: Updated on the busy-loops, also removed the unnecessary statics, here comes the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.04/ Thanks, Amy On 7/12/16 2:33 PM, David Holmes wrote: Hi Amy, On 12/07

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

> On 11 Jul 2016, at 18:58, Jim Laskey (Oracle) wrote: > >> How about the following helper method on ModulePool: >> >> Optional findModule(ModuleEntry me); >> >> then the intent in code might be a littler clearer on the context. > > After thinking about this at bit: If we did that and then la

Re: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

On 2016-07-11 18:18, Volker Simonis wrote: Hi, here comes a new version of this change. I've tried to address most of the concerns/suggestions: http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v1/ Looks good. As I'm currently obsessing about startup performance, I did wish we could

RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors Re: ByteBuffer views, alignment, word tearing

Hi Andrew, Would you mind formally reviewing the patches? Including hotspot-dev as i have updated a hotspot test so should probably push to hs. I rebased to hs and fixed a silly bug in generated heap view buffers that were incorrectly calculating the unsafe byte offset: http://cr.openjdk.j

Re: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

On Tue, Jul 12, 2016 at 2:50 PM, Claes Redestad wrote: > > > On 2016-07-11 18:18, Volker Simonis wrote: >> >> Hi, >> >> here comes a new version of this change. I've tried to address most of >> the concerns/suggestions: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v1/ >> > > Look

Re: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

On Tue, Jul 12, 2016 at 4:27 AM, Mandy Chung wrote: > >> On Jul 12, 2016, at 12:18 AM, Volker Simonis >> wrote: >> >> Hi, >> >> here comes a new version of this change. I've tried to address most of >> the concerns/suggestions: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v1/ >

Re: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

On 07/12/2016 03:54 PM, Volker Simonis wrote: Please find the new webrev at: http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v2/ +1 Any other comments? Only to note that this adds a validation check that we don't have trailing zeros, which I was recently made aware of is being rec

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

This message is only the reviewers having friendly discussion with each other! On Mon, Jul 11, 2016 at 11:44 PM, David Holmes wrote: > private static final AtomicReference firstThrowable >> = new AtomicReference<>(); >> private static final AtomicReference secondThrowable >>

RFR (JAXP): 8148350: Element.setAttributeNS() empty namespace does not throw exception

Hi, Please, help to review the fix for org.w3c.dom.Element#setAttributeNS method in JDK9: According to w3.org documentation empty string cannot be used as a namespace name [1]. Therefore the setAttributeNS [2] should raise DOMException (NAMESPACE_ERR) when namespaceURI is empty string (similar

RE: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

Hi. >> Please find the new webrev at: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v2/ > > +1 > >> Any other comments? > Only to note that this adds a validation check that we don't have > trailing zeros, which I was recently made aware of is being > reconsidered, see https://

Re: Create java.util.stream.Stream from Iterator / Enumeration

Hi Paul, I finally got the time to create the enhancement issue JDK-8161230 for the alternative methods returning a Stream instead of an Enumeration. Cheers Patrick > I had marked ClassLoader as an area to use Stream (we went through a >> bunch of areas that return Enumeration and add Stream-ba

Re: RFR (JAXP): 8148350: Element.setAttributeNS() empty namespace does not throw exception

Hi Aleksej, The change looks good. Ideally though, it would be good to update the relevant Javadoc to reflect the change since this part of Javadoc is quite explicit about when NAMESPACE_ERR is thrown. Also, this is a good opportunity to update the Lic header. Thanks, Joe On 7/12/2016 11:04

Re: RFR (JAXP): 8148350: Element.setAttributeNS() empty namespace does not throw exception

Looks OK also. Joe given this is a change in functionality, it might need a CCC fast tracked before it is pushed? > On Jul 12, 2016, at 4:03 PM, huizhe wang wrote: > > Hi Aleksej, > > The change looks good. Ideally though, it would be good to update the > relevant Javadoc to reflect the cha

Re: RFR (JAXP): 8148350: Element.setAttributeNS() empty namespace does not throw exception

On 7/12/2016 1:35 PM, Lance Andersen wrote: Looks OK also. Joe given this is a change in functionality, it might need a CCC fast tracked before it is pushed? Agree. A quick CCC to clarify the spec would be good. -Joe On Jul 12, 2016, at 4:03 PM, huizhe wang

RFR - 8141148: LDAP "follow" throws ClassCastException with Java 8

Hi folks, Looking for a review for this change: https://bugs.openjdk.java.net/browse/JDK-8141148 http://cr.openjdk.java.net/~robm/8141148/webrev.01/ A fairly straightforward fix for a class cast problem. From the bug: As a result of https://bugs.openjdk.java.net/browse/JDK-7072353: http://hg.o

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

ping. simple fix. On 7/11/16, 3:53 PM, Xueming Shen wrote: Hi, Please help review the change for JDK-7031075. issue: https://bugs.openjdk.java.net/browse/JDK-7031075 webrev: http://cr.openjdk.java.net/~sherman/7031075/webrev This is a corner case in current implementation, in which the "readE

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

Hi Sherman, A quick question. Is "inf.finished()" the only condition that needs to be checked in order to determine reachEOF? In read(), for instance, they use union: if (inf.finished() || inf.needsDictionary()) reachEOF = true; Otherwise it seems to me it could be the case t

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

> On 12 Jul 2016, at 23:38, Pavel Rappo wrote: > > Hi Sherman, > > A quick question. Is "inf.finished()" the only condition that needs to be > checked in order to determine reachEOF? In read(), for instance, they use > union: > >if (inf.finished() || inf.needsDictionary()) >reachE

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

On 7/12/16, 3:40 PM, Pavel Rappo wrote: On 12 Jul 2016, at 23:38, Pavel Rappo wrote: Hi Sherman, A quick question. Is "inf.finished()" the only condition that needs to be checked in order to determine reachEOF? In read(), for instance, they use union: if (inf.finished() || inf.needsDictio

Review request: JDK-8160398 (jdeps) Replace a list of JDK 8 internal API for detecting if it's removed in JDK 9 or later

This patch includes a generated list of JDK 8 internal packages (a trimmed down list) such that jdeps can determine if any JDK internal API is referenced but removed in JDK 9 or later release. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160398/webrev.00/ Mandy

Re: RFR: 8159684: (tz) Support tzdata2016f

I don't think it's appropriate to add 8159684 to TimeZoneTest.java which doesn't test the data changes of 2016e/f at all. I think there should be a time zone data test in java.time to confirm the tzdata changes. Otherwise, the changes look good to me. Thanks, Masayoshi On 7/12/2016 6:27 PM, R