RE: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is

Hi Frank, this is awesome. Some minor things I saw while looking through the webrev: src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java Update copryright year Remove: 20 /* 21 * $Id: AbstractTranslet.java,v 1.6 2006/06/19 19:49:03 spericas Exp $

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi, I'm sorry for that. Our solaris builds were fine. I saw the fix. Thanks Erik for fixing! I thought windows was the last platform not to support declarations in the code. Do you mind sharing what compiler choked on this? Maybe we can setup our build accordingly. And, is there a wiki page tha

Re: RFR: jsr166 jdk9 integration wave 13

I see that SpliteratorTraversingAndSplittingTest tests far more collection implementations than Collection8Test does, but we now have tests that caught spliterator bugs not caught by SpliteratorTraversingAndSplittingTest. Our tests of Spliterators are often comingled with other test methods, e.g.

RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..)

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171133 webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..): if LocateRegistry.createRegistry(port) return null

Re: Unexpected BindException in Endpoint.publish

Hi all, May I ask has there been any progress on this issue? Actually we are also struggling with this problem. The software that we are working on do publish with 0.0.0.0 and we got this BindException while migrating to JDK 8. We tried several workarounds but it will be very inconvenient for

JDK 9 RFC on 8151955: java.util.prefs: removeNode() / removeNodeSpi(): Node is permanently removed even when no flush() is invoked

The issue [1] does not seem like a bug to me as the behavior appears to be as expected from the specification but I would like to see whether anyone else agrees. Assuming the nodes “userRoot/a” and “userRoot/a/a1” do not already exist, if the test [2] is run twice in succession, the printed out

Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

Hi Joe, I just finished looking at this also and it seems fine. > On Dec 13, 2016, at 7:42 PM, Joe Wang wrote: > > Thanks Christoph! > > I updated the webrev for the classes you mentioned below, in a few cases, > used NetBeans' source format feature -- not for all of the classes though > (e

Re: (urgent) RFR: JDK-8171245: Solaris builds fails after JDK-8170663

Thanks Erik. On 15/12/2016 4:23 AM, Erik Joelsson wrote: Hello, Please review this small fix for a warning in java_md_solinux.c which was introduced with JDK-8170663. The error message is: "/opt/jprt/jprtadm/erik/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 519: error

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi Goetz, On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: object to the change to k_standard.c for the same reason. Ok, I remove that too. I had not realized this was to be pushed directly to jdk9/dev. It broke builds on Solaris and so was obviously not tested. David Best regards, G

RE: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance

+1 This is cool :) > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 14. Dezember 2016 20:26 > To: Aleks Efimov > Cc: core-libs-dev > Subject: Re: RFR (JAXP) 8146271: File system contention in debug print

Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

Thanks Christoph! On 12/13/16, 11:53 PM, Langer, Christoph wrote: Thanks, Joe. Overall, this looks better. -Original Message- From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Mittwoch, 14. Dezember 2016 01:42 To: Langer, Christoph Cc: core-libs-dev@openjdk.java.net Subject: Re: RF

Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type

On 12/14/16, 8:28 AM, Langer, Christoph wrote: Hi Joe, ok, the test is added: http://cr.openjdk.java.net/~clanger/webrevs/8169112.1/ I'm ready to push, once you are ok with it. Yes, looks good. One question: Is the copyright

Re: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance

Hi Aleksej, Looks good. Thanks for covering the whole packages! Best, Joe On 12/14/16, 10:04 AM, Aleks Efimov wrote: Hi Joe, Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier' instead of 'String'? Such approach wil

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi Chris, looks good to me. I already created a patch / branch of Apache Lucene that uses your proposed API and removes the Runnable hack. You can see it and check it out on Github: For your info the issue description and descripti

Re: (urgent) RFR: JDK-8171245: Solaris builds fails after JDK-8170663

Looks good. Naoto On 12/14/16 10:23 AM, Erik Joelsson wrote: Hello, Please review this small fix for a warning in java_md_solinux.c which was introduced with JDK-8170663. The error message is: "/opt/jprt/jprtadm/erik/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 519:

(urgent) RFR: JDK-8171245: Solaris builds fails after JDK-8170663

Hello, Please review this small fix for a warning in java_md_solinux.c which was introduced with JDK-8170663. The error message is: "/opt/jprt/jprtadm/erik/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 519: error: declaration can not follow a statement (E_DECLARATION

Re: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance

Hi Joe, Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be il

Re: RFR: jsr166 jdk9 integration wave 13

Yeah, I'm not happy with Arrays.rangeCheck. It's hotspot's job to do (and optimize away) array bounds checks, and provide informative exception messages when a check fails. On at least one occasion I wanted to have fromIndex > toIndex be a no-op. The exceptions on Arrays.fill are all spec'ed out

Re: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections

Hi Rob, The expire(long) method is already synchronized, so there's no need to call synchronized(this) inside, unless you forgot to to remove synchronized from the method declaration? I wonder if 'conns' could be created as a CopyOnWriteArrayList. Then maybe no synchronization would be needed? I

Re: RFR: jsr166 jdk9 integration wave 13

> On 13 Dec 2016, at 19:37, Martin Buchholz wrote: > > Hotspot appears to have support for the array filling code pattern, but > Arrays.fill itself is not intrinsified. Yes. I suspect in general it should be ok here. FWIW i still would like to make it an explicit intrinsic and improve the cod

RE: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type

Hi Joe, ok, the test is added: http://cr.openjdk.java.net/~clanger/webrevs/8169112.1/ I'm ready to push, once you are ok with it. One question: Is the copyright year of WithParam.java really 2016 or should it be corrected? I guess I should also request a downport to jdk8 immediately, as it is

Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections

Hi folks, Looking for a review of this change: http://cr.openjdk.java.net/~robm/8169465/webrev.01/ This is necessary to fix a potential problem where recursive ldap calls can potentially cause a deadlock with the PoolCleaner thread. See: https://bugs.openjdk.java.net/browse/JDK-8169465 -Ro

Re: RFR: JDK-8164923, JDK-8170566, JDK-8169482, JDK-8170653

Hi Abhijit, These editorial corrections are fine. Roger On 12/14/2016 1:18 AM, Abhijit Roy wrote: Hi all, Please review the java doc fixes for the below bugs: Bug: https://bugs.openjdk.java.net/browse/JDK-8164923 Description: Error in the documentation for java.lang.Random Webrev: ht

Re: JDK 9 RFR of JDK-8171234: Remove intermittent key from test java/nio/charset/coders/BashStreams.java

Looks fine. On 14/12/2016 13:06, Amy Lu wrote: java/nio/charset/coders/BashStreams.java This test was failing intermittently, related issue JDK-8149712 does not exist anymore. Test has been brought back to run since 9/142 and no open bugs (no failure reported) since then. This patch is to

JDK 9 RFR of JDK-8171234: Remove intermittent key from test java/nio/charset/coders/BashStreams.java

java/nio/charset/coders/BashStreams.java This test was failing intermittently, related issue JDK-8149712 does not exist anymore. Test has been brought back to run since 9/142 and no open bugs (no failure reported) since then. This patch is to remove @key intermittent from the test. bug: http

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Webrev updated in-place. http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ -Chris. On 13/12/16 21:18, Peter Levart wrote: I think this is OK. Just a couple of nits in test: 1. You create a static Path bob = Paths.get("bob") field, but then you don't use it in: 56 try (File

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

> object to the change to k_standard.c for the same reason. Ok, I remove that too. Best regards, Goetz. > -Original Message- > From: David Holmes [mailto:david.hol...@oracle.com] > Sent: Mittwoch, 14. Dezember 2016 12:29 > To: Lindenmaier, Goetz ; > daniel.daughe...@oracle.com; 'Dmitry

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: Hi, You're right, I had removed the change to e_asin.c. You only pointed Joe to that file AFAICS. I would expect he would also object to the change to k_standard.c for the same reason. New webrev anyways: http://cr.openjdk.java.net/~goetz/wr

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi, You're right, I had removed the change to e_asin.c. New webrev anyways: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. Best regards, Goetz. > -Original Message- > From: David Holmes [mailto:d

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: Hi David, I found "8169317: [s390] Various minor bug fixes and adaptions." in jdk9/dev this morning, so I thought it has been promoted based on some older change. I waited for that quite a while because tests in jdk9/dev kept failing on s390. How

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi David, I found "8169317: [s390] Various minor bug fixes and adaptions." in jdk9/dev this morning, so I thought it has been promoted based on some older change. I waited for that quite a while because tests in jdk9/dev kept failing on s390. How can I get the information when what was promoted?

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: Hi, 8066474 has not been promoted. hs has not been able to push up to dev yet. I'll remove the strlen // fix for aix from this change and push it without it. I'd like to get this done. I've lost track of what is now left in this set of chang

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi, 8066474 has not been promoted. I'll remove the strlen // fix for aix from this change and push it without it. I'd like to get this done. Best regards, Goetz. > -Original Message- > From: David Holmes [mailto:david.hol...@oracle.com] > Sent: Donnerstag, 8. Dezember 2016 23:03 > To