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() ||

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

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

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:

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

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

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

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

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

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: 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

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

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

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:

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

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: --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

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

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,

Re: --dry-run description enhancement

On 12/07/2016 4: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 (resolution) and initialization are all distinct parts

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

On 12/07/2016 4:17 PM, Martin Buchholz wrote: Amy, sorry you have so many picky reviewers! Difference between patching a failing test and completely redesigning it from scratch. The latter was not warranted in my opinion. Here's how I might write it: import

Re: --dry-run description enhancement

Hi Paul, On 7/12/16 8:00 AM, 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. So my inference was that the class does not get loaded into memory

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

Hi Amy, On 12/07/2016 3:28 PM, Amy Lu wrote: Please help to review the updated webrev, getting rid of ThreadDeath and using join(): http://cr.openjdk.java.net/~amlu/8132548/webrev.03/ I still think a simple change to the original code suffices, but given you have gone this far ...

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

And then somehow the unnecessary statics started to bother me: import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicReference; public class Stop { public static void main(String[] args) throws Exception { final CountDownLatch ready = new

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

Amy, sorry you have so many picky reviewers! Here's how I might write it: import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicReference; public class Stop { private static final CountDownLatch ready = new CountDownLatch(1); private static final

Re: --dry-run description enhancement

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. So my inference was that the class does not get loaded into memory because the latter no longer occurs with --dry-run.