RFR (JAXP) JDK-8169829 ProblemList update for javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh

Hi all This is to correct the bugid in ProblemList.txt, see Bug: https://bugs.openjdk.java.net/browse/JDK-8169829 Would you like to have a review http://cr.openjdk.java.net/~fyuan/8169829/webrev.00/? Thanks, Frank

RE: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

Hi Joe, this looks good and contains nice cleanups (some of them I have as well in my changes for 8169631 :) ). Some formatting nits: src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java: line 975 map.put(className+".class", attr); spaces left and

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

Brent - the null check in Class::getResourceXXX looks really odd, particularly because resolveName accepts null. Since we've changed this in the jake forest to do the right thing then I'm wondering if it would be better if you dropped this part from your patch, would that be okay? -Alan On

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

Hi Chris, Joe, Roger, Thank you for reviewing. Please check the comments inline. new webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.01/ Thank you -Hamlin On 2016/11/17 2:30, joe darcy wrote: In terms of timeout, please use much shorter timeout, seconds not minutes. In case of

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

Adding in build-dev as they need to scrutinize all build changes. David On 17/11/2016 11:45 AM, Gustavo Romero wrote: Hi, Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. As a consequence on PPC64 (Linux) StrictMath methods like, but not

Re: JShell doesn't provide a ToolProvider

On 11/16/16 15:00, fo...@univ-mlv.fr wrote: So i respectfully disagree with Robert :) While the interactive mode of jshell is something important, being able to replay interactive sessions (stored in a file) automatically is in my opinion as important. If the module jdk.jshell provide an

PPC64: Poor StrictMath performance due to non-optimized compilation

Hi, Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, sin(), cos(), and tan() perform verify poor in comparison to the same methods in Math class [2]:

Re: Proposed patch: further wrapping of FileInputStream's native method

> On 16 Nov 2016, at 16:13, Claes Redestad wrote: > > Hi Paul, > > it appears you missed out on all the fun this time: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044628.html > Indeed! I missed that it moved to a separate email thread.

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

On 11/16/16 3:44 PM, Paul Sandoz wrote: Hi Brent, I think it would be better to use Objects.requireNonNull Yes, thank you - forgot about that. IMHO no need to specify a exception message, or test for that (which i think is too brittle). OK. Updated webrev:

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

The rather-hard-to-decode section 12.6.2 essentially tries to pin down exactly when a reference is guaranteed to remain reachable. It may be worth directly pointing to it. (And perhaps wishing the reader luck :-) ) On Wed, Nov 16, 2016 at 12:21 AM, Zoltán Majó wrote: >

Re: Proposed patch: further wrapping of FileInputStream's native method

Hi Paul, it appears you missed out on all the fun this time: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044628.html Thanks! /Claes On 2016-11-17 00:50, Paul Sandoz wrote: Hi Sunny, If you send me an exported patch with the reviewers in the comment etc i can push

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

On 17/11/2016 10:00 AM, Peter Levart wrote: Hi David, On 11/17/2016 12:35 AM, David Holmes wrote: Why are we insisting in specifying when it is guaranteed for a Reference object to *not* be enqueued. This is not very helpful. I disagree. The whole point of the statement was to make it clear

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

+1 Masayoshi On 11/15/2016 1:07 AM, Naoto Sato wrote: +1 Naoto On 11/13/16 11:12 PM, Rachna Goel wrote: Hi, Kindly review fix for JDK-8168906. https://bugs.openjdk.java.net/browse/JDK-8168906 Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ fix: As jdk.localedata module does

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

test/sun/util/locale/provider/Bug8152817.java is a test with a SecurityManager. I18n SQE should have some. Masayoshi On 11/14/2016 11:59 PM, Sean Mullan wrote: Looks good. Are there any regression tests for this component that run with a SecurityManager? If not, it would be useful to add

Re: RFR: jsr166 jdk9 integration wave 12

Apologies for having this wave turn into a tsunami. CopyOnWriteArrayList was rewritten due to finding https://bugs.openjdk.java.net/browse/JDK-8169738 ArrayDeque and ArrayBlockingQueue now both use efficient nested loop idiom for all traversals. Most bulk remove methods in all collection classes

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Hi David, On 11/17/2016 12:35 AM, David Holmes wrote: Why are we insisting in specifying when it is guaranteed for a Reference object to *not* be enqueued. This is not very helpful. I disagree. The whole point of the statement was to make it clear that for a referent to be enqueued the

Re: Proposed patch: further wrapping of FileInputStream's native method

Hi Sunny, If you send me an exported patch with the reviewers in the comment etc i can push for you. Thanks, Paul. > On 9 Nov 2016, at 19:02, Chan, Sunny wrote: > > Hello all, > > I proposed a patch to provide wrapping for some native methods in > FileInputStream a while

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

Hi Brent, I think it would be better to use Objects.requireNonNull (see other usages in Class etc). IMHO no need to specify a exception message, or test for that (which i think is too brittle). You will need to file a CCC for the change in behaviour of the Enumeration returning getResources.

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

On 17/11/2016 9:15 AM, Peter Levart wrote: Hi Zoltan, On 11/16/2016 10:27 PM, David Holmes wrote: Peter has highlighted the risk with anything but the most minimal of changes - the more you say the more likely you are saying something that is incorrect. Reachability and the GC relationship to

Re: RFR: jsr166 jdk9 integration wave 12

Hi Martin, Glad you looked more closely at the perf aspects of ArrayDeque. I am struggling to determine what has changed since the last revision. Apart from ArrayDeque what files should i be looking at? Thanks, Paul. > On 16 Nov 2016, at 12:14, Martin Buchholz wrote: >

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

On 11/16/2016 10:31 PM, Mandy Chung wrote: On Nov 16, 2016, at 12:41 AM, Zoltán Majó wrote: When a reference becomes unreachable (not by examining the source code but the actual state of the VM at runtime), it will never be enqueued. I also like that wording,

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

Hi, Please review my fix for 8136831 - Undefined null behavior in Class[Loader].getResource(). Bug: https://bugs.openjdk.java.net/browse/JDK-8136831 Webrev: http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/ Class and ClassLoader have the following public methods for locating

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Hi Zoltan, On 11/16/2016 10:27 PM, David Holmes wrote: Peter has highlighted the risk with anything but the most minimal of changes - the more you say the more likely you are saying something that is incorrect. Reachability and the GC relationship to it is extremely complex and can't be

Re: JShell doesn't provide a ToolProvider

So i respectfully disagree with Robert :) While the interactive mode of jshell is something important, being able to replay interactive sessions (stored in a file) automatically is in my opinion as important. If the module jdk.jshell provide an implementation for the interface ToolProvider

RE: Proposal for adding O_DIRECT support into JDK 9

Hi All, Our most recent version of our DirectIO patch is available at http://cr.openjdk.java.net/~kkharbas/8164900/webrev.04/ In this version, we have modified the following items: 1. Remove ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned(). Instead, using existing APIs

RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

Hi, Please review an enhancement adding a property to allow for specifying the chunk size of CDATA. JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ Thanks, Joe

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

> On Nov 16, 2016, at 12:41 AM, Zoltán Majó wrote: > > >> When a reference becomes unreachable (not by examining the source code but >> the actual state of the VM at runtime), it will never be enqueued. > > I also like that wording, thank you! BTW I am not proposing

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Peter has highlighted the risk with anything but the most minimal of changes - the more you say the more likely you are saying something that is incorrect. Reachability and the GC relationship to it is extremely complex and can't be summarised in a few words. I would go back to the original

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

> On Nov 16, 2016, at 12:30 PM, David DeHaven wrote: > > Round 3: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.2 > > Tested with a jar that had a bad JavaFX-Application-Class and it continued to > report the correct class name. +1 Mandy

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

>> Please review the (fairly straightforward) JDK changes needed to support >> launching JavaFX applications in a named module. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8169289 >> >> Webrev: >> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/

Re: RFR 8132097: Stream.generate should use a covariant Supplier as parameter

Looks good to me! On Tue, Nov 8, 2016 at 4:43 PM, Paul Sandoz wrote: > Hi > > Please review this compatible fix to Stream.generate to accept a covariant > Supplier. > > Paul. > > diff -r 3e3ca9800322 src/java.base/share/classes/ > java/util/stream/Stream.java > ---

Re: RFR: jsr166 jdk9 integration wave 12

Thanks to Vitaly and Doug for being more concerned about offer/poll performance than I was initially. ArrayDeque is now back to using the head + tail + spare slot strategy, which keeps optimal performance for non-bulk operations, while everything else gets faster. We have new tests and new

Re: 8072784: Better spliterator implementation for BitSet.stream()

> On 16 Nov 2016, at 07:21, Martin Buchholz wrote: > > should the spec say that the spliterator is late binding? > I logged this issue: https://bugs.openjdk.java.net/browse/JDK-8169808 We sold also consider

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

In terms of timeout, please use much shorter timeout, seconds not minutes. Most JDK regression tests complete in well under 10 seconds and few tests should run for as long as a minute. Also, please scale any timeout if a timeout factor retrieved from the jtreg environment. This allows the test

Re: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations

Thanks Roger, On 16/11/16 16:03, Roger Riggs wrote: Hi Daniel, DocumentBuilderFactory and classes: - The new methods uses "Creates" instead of "Obtain"; perhaps it should be consistent with existing newInstance methods? I had some pre-review advice from Joe (Wang) about who suggested

Re: Request to review: JDK-8169659 (JDK-8168836 seems the wrong id)

+1 I will sponsor it. Mandy > On Nov 16, 2016, at 2:37 AM, Patrick Reinhart wrote: > > Hi Mandy, > > It seem so me I made the webrev using the wrong issue, here is the correct > URL including the changes that you have suggested > >

Re: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations

> On Nov 16, 2016, at 12:18 PM, Joe Wang wrote: > > > > On 11/16/16, 8:03 AM, Roger Riggs wrote: >> Hi Daniel, >> >> DocumentBuilderFactory and classes: >> - The new methods uses "Creates" instead of "Obtain"; >> perhaps it should be consistent with existing

Re: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations

On 11/16/16, 8:03 AM, Roger Riggs wrote: Hi Daniel, DocumentBuilderFactory and classes: - The new methods uses "Creates" instead of "Obtain"; perhaps it should be consistent with existing newInstance methods? "Obtain" was used in the early version of JAXP, and "Creates" in newer

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

> On 16 Nov 2016, at 07:36, Hamlin Li wrote: > > Would you please review below fix? > > bug: https://bugs.openjdk.java.net/browse/JDK-8168975 > webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ The approach builds on the mechanism put in for 8168975, and seems

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Hi, On 11/16/2016 05:09 PM, Peter Levart wrote: http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ "If a registered reference ceases to be strongly reachable itself (not by examining the source code but by looking at the actual state of the VM at runtime), it will never be enqueued." I

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Hi Zoltan, Mandy, On 11/16/2016 09:41 AM, Zoltán Majó wrote: Hi Mandy, On 11/16/2016 07:11 AM, Mandy Chung wrote: On Nov 15, 2016, at 4:41 AM, Zoltán Majó wrote: I think the sentence in webrev.01 (1) "If a registered referenceceases to be strongly reachable

Re: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations

Hi Daniel, DocumentBuilderFactory and classes: - The new methods uses "Creates" instead of "Obtain"; perhaps it should be consistent with existing newInstance methods? - "Otherwise," and "Otherwise" (with and without ",") are not consistent in the webrev. XMLInputFactory.java:

[JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations

Hi, Please find below a patch for: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations bug: https://bugs.openjdk.java.net/browse/JDK-8169778 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ best regards,

Re: 8072784: Better spliterator implementation for BitSet.stream()

should the spec say that the spliterator is late binding? On Wed, Nov 16, 2016 at 7:13 AM, Martin Buchholz wrote: > I've been looking, but all I got is: > s/passed/past/ >

Re: 8072784: Better spliterator implementation for BitSet.stream()

I've been looking, but all I got is: s/passed/past/

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

Sorts options by full name http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8168256

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

Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev:

RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource

Hi, to address the long standing bug 8023653 I propose the following change: webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ bug: https://bugs.openjdk.java.net/browse/JDK-8023653 I think the bug report in general complains that the default for DOMSource input is to parse the

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

Yes. Stephen On 16 November 2016 at 09:08, nadeesh tv wrote: > Hi Roger , > > Could I push the webrev? > > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > Thanks and regards, > Nadeesh > > > On 11/7/2016 6:05 PM, Anubhav Meena wrote: > > Thanks for the

Re: JShell doesn't provide a ToolProvider

On 16/11/2016 09:23, Remi Forax wrote: Hi all, hi Robert, currently, unlike javac or javadoc, there is no way to directly invoke jshell (JShellTool) because it lies in an internal package (which is a good idea). I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i

Re: JShell doesn't provide a ToolProvider

- Mail original - > De: "Patrick Reinhart" > À: "Remi Forax" > Cc: "core-libs-dev" > Envoyé: Mercredi 16 Novembre 2016 11:29:55 > Objet: Re: JShell doesn't provide a ToolProvider > Hi Remi, > > At the moment there

Request to review: JDK-8169659 (JDK-8168836 seems the wrong id)

Hi Mandy, It seem so me I made the webrev using the wrong issue, here is the correct URL including the changes that you have suggested http://cr.openjdk.java.net/~reinhapa/reviews/8169659/webrev.00 Sorry, for the confusion... -Patrick On 2016-11-15 00:20, Mandy Chung wrote: On Nov 14,

Re: JShell doesn't provide a ToolProvider

Hi Remi, At the moment there is only the both outputs and the arguments. So there seems to be no way to actually interact with a ToolProvider using the "run" method. Since there is no way to interact, the benefit is not given this way or am I wrong here? -Patrick On 2016-11-16 10:23, Remi

JShell doesn't provide a ToolProvider

Hi all, hi Robert, currently, unlike javac or javadoc, there is no way to directly invoke jshell (JShellTool) because it lies in an internal package (which is a good idea). I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i can embed jshell, like i can embed any

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

Hi Roger , Could I push the webrev? http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ Thanks and regards, Nadeesh On 11/7/2016 6:05 PM, Anubhav Meena wrote: Thanks for the review! Here is the updated webrev

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Hi Mandy, On 11/16/2016 07:11 AM, Mandy Chung wrote: On Nov 15, 2016, at 4:41 AM, Zoltán Majó wrote: I think the sentence in webrev.01 (1) "If a registered referenceceases to be strongly reachable itself, then it may never be enqueued." is sufficient. I think we

Re: RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review

+1 -Sundar On 11/15/2016 11:27 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8169505 > >

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

Hi David, On 11/16/2016 03:21 AM, David Holmes wrote: Hi Zoltan, First, I'm okay with latest webrev. thank you. Second, I don't want to confuse things but need to correct one thing ... I think you rather clarified things. On 15/11/2016 10:41 PM, Zoltán Majó wrote: [...] For