Re: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource

Hi Christoph, XMLReaderManager, 175 - 186 can be replace with: JdkXmlUtils.setXMLReaderPropertyIfSupport(reader, NAMESPACES_FEATURE, m_NamespaceAware, false); JdkXmlUtils.setXMLReaderPropertyIfSupport(reader, NAMESPACE_PREFIXES_FEATURE, !m_NamespaceAware, false); The new test

Re: RFR: jsr166 jdk9 integration wave 12

No more rework is planned!

Re: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX()

+1 Mandy > On Nov 18, 2016, at 1:20 PM, Brent Christian > wrote: > > Hi, > > Thank you to Paul for pointing out to me that ClassLoader.resources() also > falls into this category. > > I have updated resources() to follow suit, along with test code (and Mandy's > suggested test changes) in t

Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

Hi Christoph, Thanks for explaining the customer's dilemma with regard to their legacy process. The testcase I sent you was extracted from an internal SQE smoke test. I agree with your analysis, the 'golden' file which has been in there for over 10 years turns out to be wrong and needs to be

Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

On 11/18/16, 12:17 PM, Langer, Christoph wrote: Hi Joe, Yep, I'll conduct the testing before pushing. With the "Expected Result", you mean some comment for the test method, right? Yes, some comment for the test method would do. But I see that you've added assertions? That would be even

RE: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

Hi Joe, thanks for the feedback. I've now understood the testcase that you've sent over and the reason that it is reporting failure after my fix is that the output of its transform operation is rather correct now. And before it was wrong. :) The test is comparing the actual result to a "golden"

Re: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX()

Hi, Thank you to Paul for pointing out to me that ClassLoader.resources() also falls into this category. I have updated resources() to follow suit, along with test code (and Mandy's suggested test changes) in this updated webrev: http://cr.openjdk.java.net/~bchristi/8136831/webrev.03/ Than

Re: RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order

> On Nov 16, 2016, at 7:00 AM, Jim Laskey (Oracle) > wrote: > > Sorts options by full name > > http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8168256 > 113 public Option(boolean hasArg, Processing processing, String name, St

Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

On 2016-11-18 16:30, Erik Joelsson wrote: Hello, Please review this change which removes the $ARCH sub directory in the lib directory of the runtime images, which is an outstanding issue from the new runtime images. Most of the changes are in the build, but there are some in hotspot and launc

RE: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

Hi Joe, Yep, I'll conduct the testing before pushing. With the "Expected Result", you mean some comment for the test method, right? Thanks Christoph From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Freitag, 18. November 2016 20:00 To: Langer, Christoph Cc: core-libs-dev@openjdk.java.net Su

Re: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0

> On 18 Nov 2016, at 06:52, Claes Redestad wrote: > > Hi, > > having classes ask the security manager for permission to access its own > class loader > when probing for assertion status during class initialization appears > pointless. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169993

Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

Looks good, Christoph. I assume you'll do an all-test run (all in jaxp/test) before pushing. No need for further review, but it'd be nice to add an "Expected result" for the new test testBug8169772, with/without the fix (e.g. NPE). Best regards, Joe On 11/18/16, 4:38 AM, Langer, Christoph w

Re: RFR: jsr166 jdk9 integration wave 12

Regarding the testing mess: I think there should be a project to use Junit 5 features to create interface based tests. Then a BlockingDeque implementation could easily pull in all the tests already written for BlockingDeque and its superinterfaces. Tests for interfaces would be found in a predic

Re: RFR: jsr166 jdk9 integration wave 12

I encourage you to look at the experiments in the valhalla repository. Such as: http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/780c8eba356a/src/java.base/share/classes/java/anyutil/ArrayDeque.java

Re: RFR: jsr166 jdk9 integration wave 12

Here's a few more places to apply Remi's rule: --- src/test/tck/Collection8Test.java 15 Nov 2016 23:08:30 - 1.27 +++ src/test/tck/Collection8Test.java 18 Nov 2016 17:21:19 - @@ -304,7 +304,7 @@ switch (rnd.nextInt(4)) { case 0: survivors.addAll(c); break;

RE: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Joe, Although neither a floating point expert (as I think I've proven to you over the years), or a gcc expert, I checked with our in-house gcc expert and got this following answer: "Yes using -fno-strict-aliasing fixes the issues. Also there are many forks of fdlibm which has this

Re: RFR: jsr166 jdk9 integration wave 12

> On 18 Nov 2016, at 08:46, Martin Buchholz wrote: > > > > On Thu, Nov 17, 2016 at 11:17 PM, Remi Forax > wrote: > - Mail original - > > De: "Martin Buchholz" mailto:marti...@google.com>> > > À: "Paul Sandoz" mailto:paul.san...@oracle.com>> > > Cc: "core-libs

Re: RFR: jsr166 jdk9 integration wave 12

On Fri, Nov 18, 2016 at 5:02 AM, Doug Lea wrote: > On 11/18/2016 02:28 AM, Remi Forax wrote: > >> Martin, >> for ArrayDeque, when you start to have methods like >> @SuppressWarnings("unchecked") >>static final E elementAt(Object[] es, int i) { >>return (E) es[i]; >>} >> >> I th

Re: RFR: jsr166 jdk9 integration wave 12

> On 18 Nov 2016, at 04:52, Doug Lea wrote: > > >> On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > > wrote: >> >> >>Semaphore >>— >> >> 633 /** >> 634 * Acquires and returns all permits that are immediately >>available. >> 635

Re: RFR: jsr166 jdk9 integration wave 12

On Thu, Nov 17, 2016 at 11:17 PM, Remi Forax wrote: > - Mail original - > > De: "Martin Buchholz" > > À: "Paul Sandoz" > > Cc: "core-libs-dev" > > Envoyé: Vendredi 18 Novembre 2016 05:29:12 > > Objet: Re: RFR: jsr166 jdk9 integration wave 12 > > [..] > > > >> 317 c.forEach(e -

Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Finally! :) Hotspot changes looks fine to me. But you missed hotspot/make/hotspot.script file. Our colleges in RH and SAP should test these changes on their platforms. Next step would be removal of client/server sub-directories on platforms where we have only Server JVM (64-bit JDK has only

Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Erik: Please review this change which removes the $ARCH sub directory in the lib directory of the runtime images, which is an outstanding issue from the new runtime images. Most of the changes are in the build, but there are some in hotspot and launcher source. I have verified -testset hotspot a

Re: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart()

Hi Hamlin, RMID.java: - import of LocalTime would lexically follow jva.rmi - 53-54 typos: "ajust" -> "adjust"; "togeter" -> "together" RMIDSelectorProvider.java: - 121, 125 I would have just used System.out.printf directly without introducing a trivial function. Looks fine, Roger Rog

Re: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module

On 18/11/16 14:09, Sergei Kovalev wrote: Hi Daniel, Thank you for feedback. You absolutely right about modules. To have an ability to distinguish environment issue from test pass I've added a warning message how you recommended. At least it will have a visible effect. http://cr.openjdk.java.ne

Re: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module

Hi Sergei, UnbindIdempotent.java: - add 2016 to the copyright. Otherwise looks fine. Regards, Roger On 11/18/2016 9:09 AM, Sergei Kovalev wrote: Hi Daniel, Thank you for feedback. You absolutely right about modules. To have an ability to distinguish environment issue from test pass I'v

RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Hello, Please review this change which removes the $ARCH sub directory in the lib directory of the runtime images, which is an outstanding issue from the new runtime images. Most of the changes are in the build, but there are some in hotspot and launcher source. I have verified -testset hotsp

RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0

Hi, having classes ask the security manager for permission to access its own class loader when probing for assertion status during class initialization appears pointless. Bug: https://bugs.openjdk.java.net/browse/JDK-8169993 Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/ Tha

Re: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module

Hi Daniel, Thank you for feedback. You absolutely right about modules. To have an ability to distinguish environment issue from test pass I've added a warning message how you recommended. At least it will have a visible effect. http://cr.openjdk.java.net/~skovalev/8169721/webrev.01/ Looks l

Re: RFR: jsr166 jdk9 integration wave 12

On 11/18/2016 02:28 AM, Remi Forax wrote: Martin, for ArrayDeque, when you start to have methods like @SuppressWarnings("unchecked") static final E elementAt(Object[] es, int i) { return (E) es[i]; } I think it's a better idea to type the field elements as a E[] instead of Objec

Re: RFR: jsr166 jdk9 integration wave 12

On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz mailto:paul.san...@oracle.com>> wrote: Semaphore — 633 /** 634 * Acquires and returns all permits that are immediately available. 635 * Upon return, zero permits are available. 636 * 637

RE: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

Hi Joe, thanks for the feedback. I've created a new version of the webrev working in your suggestions, adding some further formatting cleanups in the files and I also moved a small refactoring in TransformerTest.java to this changeset. http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ >F

Re: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java

Hi John, Looks good to me. Should windows-amd64 also be listed? It appears the test also failing there (JDK-8152654) best regards, -- daniel On 18/11/16 06:02, John Jiang wrote: Hi, Track this test issue with a new JBS bug JDK-8169942. Please take a look at the updated webrew: http://cr.openj

JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

I was looking at the existing JDK 9 issues for some simple ones I could solve and found this one. I wanted to know if it makes sense to add additional constructors here? Now you need to do this: try { new PrintWriter(file, "UTF-8"); } catch (UnsupportedEncodingExcep