Re: RFR: 8162563: Fix double checked locking in System.console()

Hi David, I didn't even look at Console.java! I just fixed the double-checked locking in System.java. Looking now at Console.cons, that is NOT safely statically initialized: SharedSecrets.setJavaIOAccess(new JavaIOAccess() { public Console console() { if

Re: RFR: 8162563: Fix double checked locking in System.console()

On 27/07/2016 6:35 AM, Martin Buchholz wrote: Hi Xueming, I'd like you to do a wee code review, http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Console-double-checked-locking/ Humour me - where is the bug? We're simply retrieving the existing Console singleton that is safely published

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

MY suggestions on 2 security-related modules: java.security.jgss: The {@code java.security.jgss} module defines and exports the interfaces and classes related to the Java binding of the Generic Security Services Application Program Interface (GSS-API). This module also includes GSS-API

Re: RFR: 8162563: Fix double checked locking in System.console()

Thanks. Nice to have a change measured in hours instead of weeks...

Re: RFR: 8162563: Fix double checked locking in System.console()

+1 On 7/26/16 1:35 PM, Martin Buchholz wrote: Hi Xueming, I'd like you to do a wee code review, http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Console-double-checked-locking/

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Daniel, I tried your xsl, but I got the same result using either JDK 8 or a recent JDK 9 (jdk9dev) build: xmlns="ns2">xmlns="ns2"> For the issue with regard to empty namespace, please open a bug and let's fix it. Thanks, Joe On 7/26/16, 10:32 AM, Daniel Fuchs wrote: Hi Christoph, I

Re: RFR: 8162563: Fix double checked locking in System.console()

Hi Martin, That looks ok to me. Roger On 7/26/2016 4:35 PM, Martin Buchholz wrote: Hi Xueming, I'd like you to do a wee code review, http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Console-double-checked-locking/

RFR: 8162563: Fix double checked locking in System.console()

Hi Xueming, I'd like you to do a wee code review, http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Console-double-checked-locking/

Re: JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception

On 7/26/16 3:36 PM, joe darcy wrote: Hi Coleen, The existing tests covered *toGenericString* output with a throws clauses but omitted coverage of *toString* methods with a throws clause. That let the omission of the space character in toString output slip through. (There is some

Re: JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception

Hi Coleen, The existing tests covered *toGenericString* output with a throws clauses but omitted coverage of *toString* methods with a throws clause. That let the omission of the space character in toString output slip through. (There is some logically duplicated structure in the

Re: JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception

Thank you for fixing this so quickly. This looks good but I have a question about: http://cr.openjdk.java.net/~darcy/8162539.0/test/java/lang/reflect/Constructor/GenericStringTest.java.udiff.html @ExpectedGenericString( "protected TestClass1(S,T) throws java.lang.Exception") +

JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception

Hello, Please review the changes to address JDK-8162539: Test fails because it expects a blank between method signature and throws exception http://cr.openjdk.java.net/~darcy/8162539.0/ In brief, recent refactorings of the toString output in core reflection (JDK-8161500 Use

Re: [9] RFR: 8162343: non-ASCII characters in source code comments (.hpp)

Looks good to me, but I am not a Reviewer. Cheers, Henry On July 26, 2016 at 10:16:36 AM, Naoto Sato (naoto.s...@oracle.com) wrote: > Ping. > > On 7/21/16 3:44 PM, Naoto Sato wrote: > > Hello, > > > > Please review the change to the following issue: > > > >

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi, Updated the specdiff and javadoc with SerializablePermission and misc editorial cleanups. SpecDiff: http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html

Re: RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

Hi Svetlana, Looks ok to me. Roger On 7/25/2016 8:42 AM, Svetlana Nikandrova wrote: Hi Joe, Roger, thank you for your replays. A have changed javadoc as Joe suggested (hope I didn't missed any in-line comments) and added a bunch of "s" and "The" to Returns and @return. Hope now it looks

Re: [9] RFR: 8162343: non-ASCII characters in source code comments (.hpp)

Look fine, Roger On 7/26/2016 1:16 PM, Naoto Sato wrote: Ping. On 7/21/16 3:44 PM, Naoto Sato wrote: Hello, Please review the change to the following issue: https://bugs.openjdk.java.net/browse/JDK-8162343 The proposed fix is located at:

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Christoph, I was at first a bit suspicious of your proposed patch, but I applied it and played with it and could not fault it. Now I tend to believe this is the correct thing to do (though that's not my area of expertise). I tried it with a bit more elaborate content in the "transform"

Re: [9] RFR: 8162343: non-ASCII characters in source code comments (.hpp)

Ping. On 7/21/16 3:44 PM, Naoto Sato wrote: Hello, Please review the change to the following issue: https://bugs.openjdk.java.net/browse/JDK-8162343 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8162343/webrev.00/ It's a trivial fix following the bug 8161937. Naoto

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Chris, yes, its in the webrev, but I neglected to include it in the javadoc and specdiff updates. Thanks, Roger On 7/26/2016 12:20 PM, Chris Hegarty wrote: Another final thought that just occurred to me… java.io.SerializablePermission will need its class-level javadoc updated to

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

Hi all, Take 2 on the module description javadocs. http://cr.openjdk.java.net/~lancea/8161965 the xxx.01 include the updated changes. Alan, I tried to incorporate your suggested changes. Hopefully we are getting closer. Best Lance > On Jul 21,

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Another final thought that just occurred to me… java.io.SerializablePermission will need its class-level javadoc updated to include the new permission target name. -Chris. > On 25 Jul 2016, at 19:55, Roger Riggs wrote: > > Hi Chris, > > Thanks for the review and

RFR [9] 8160513: ClassNotFoundException sun.misc.GC when running Tomcat 9 with JDK 9

The GC.Daemon thread has no need of any user defined class loader, so should set its context class loader to null before starting, so as to not inadvertently retain a reference to the creating thread’s context class loader. http://cr.openjdk.java.net/~chegar/8160513/

Re: RFR: jsr166 jdk9 integration wave 8

> On 25 Jul 2016, at 21:25, Martin Buchholz wrote: > > Wave 8 updated with urgent temporary fix for > 8162396: j.u.c java.lang.LinkageError > Thank you for doing that. +1 JPRT run passed. Paul.

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

On 26/07/16 14:53, Langer, Christoph wrote: you mean with my webrev built in or with the current jdk9 dev? ... and with your patch applied I see this: xmlns="ns1"> cheers, -- daniel

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Christoph, On 26/07/16 14:53, Langer, Christoph wrote: Hi Daniel, you mean with my webrev built in or with the current jdk9 dev? With the current jdk9 dev - sorry if that was unclear. cheers, -- daniel public static void main(String[] args) throws XMLStreamException,

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Christoph, Joe, Actually what I see with the latest dev version of JDK 9 (eng. build built a few minutes ago) is this: xmlns="ns1"> Notice that xmlns="ns1" appears twice in the root element. So maybe there's more than one bug here :-( cheers, -- daniel On 26/07/16 12:56, Langer,

RE: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Daniel, you mean with my webrev built in or with the current jdk9 dev? Best Christoph > -Original Message- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Dienstag, 26. Juli 2016 15:47 > To: Langer, Christoph ; huizhe wang >

RE: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Joe, thanks for looking at this. Here is my comments: > I'm not sure why empty namespace was explicitly excluded. But for the > 2nd part, the developer was clear with a note on the intention. You may > want to try removing the condition statement that excluded the empty > namespace, but keep

Re: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads

On 26/07/16 10:44, Alan Bateman wrote: On 25/07/2016 18:21, Daniel Fuchs wrote: Hi, Here is the later version of the fix: - Header files fixed - Bytecode 1.1 compatible http://cr.openjdk.java.net/~dfuchs/webrev_8153082/webrev.02/ This looks okay to me although I think I'd like to

Re: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads

On 25/07/2016 18:21, Daniel Fuchs wrote: Hi, Here is the later version of the fix: - Header files fixed - Bytecode 1.1 compatible http://cr.openjdk.java.net/~dfuchs/webrev_8153082/webrev.02/ This looks okay to me although I think I'd like to understand more as to why this needs to emit v45

RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

Hi Daniel I didn't state clear, actually, I want/wanted to take the absolutely same way as your allowAll except I am going to add a common function(called runWithAllPerm) to run it, no Permission arguments any longer. I will send you a draft to you and Joe to make it clear before I finish all

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

On 26/07/16 04:24, Frank Yuan wrote: Thank you very much for your suggestions! Now I fully understand the rule(at least I think so :P) I will use a runWithAllPerm block surrounding the user setup code as Daniel's way. Btw, Daniel, ThreadLocal should not need Atomic any more, correct? Hi

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

On 7/22/2016 3:38 AM, Langer, Christoph wrote: Hi, I have a customer reporting the following phenomena which I believe is an issue. Consider the following xsl: -XSL- http://www.w3.org/1999/XSL/Transform; version="1.0">