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

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: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

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

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: http://cr.openjdk.java.net/%7Erpatil/8164923/webrev.00/ Bug : https://bugs.openjdk.java.net/browse/JDK-8

RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

An clarification is added to FilePermission::implies: * @implNote * a simple {@code npath} is recursively inside a wildcard {@code npath} * if and only if {@code simple_npath.relativize(wildcard_npath)} - * is a series of one or more "..". An invalid {@code FileP

Re: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint

> On Dec 13, 2016, at 12:53 PM, Brent Christian > wrote: > > Thank you, Mandy and Daniel. > > As a point of interest, automated testing uncovered a couple things I had to > change before pushing: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/accf1676e416 > > * Updated the CHECK_OFFSET

Re: RFR: 8169806 - DriverManager javadoc clarifications

> On Dec 13, 2016, at 2:35 PM, Lance Andersen wrote: > > Hi all, > > This review request addresses some a cleanup to the DriverManager javadocs. > The CCC for the changes has been approved. > > The webrev can be found at > http://cr.openjdk.java.net/~lancea/8169806/webrev.03/ +1 Mandy

Re: RFR: jsr166 jdk9 integration wave 13

Hotspot appears to have support for the array filling code pattern, but Arrays.fill itself is not intrinsified. There are bounds checks which hotspot may not be able to elide. For almost all software, Arrays.fill is good enough, but core library collections are an exception. Also, we introduce o

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, Thanks for the diligent work! I think we've made a great improvement over the PrettyPrint (tremendous ;-) ) Could you look into extracting the XML literal strings in the test into plain files (similar to the other 'gold' files)? What I'm hoping to see is that they'd look easily pre

Re: RFR 8168979: @implNote for invalid FilePermission

> On Dec 14, 2016, at 10:11 AM, Xuelei Fan wrote: > > On 12/13/2016 5:45 PM, Wang Weijun wrote: >> A major behavior change is that <> now implies an invalid >> permission, I hope this is good to minimize incompatibility. > Looks like two sides of the same coin. If there is an invalid <> > (no

Re: RFR 8168979: @implNote for invalid FilePermission

On 12/13/2016 5:45 PM, Wang Weijun wrote: A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. Looks like two sides of the same coin. If there is an invalid > (not existing in practice, I think), it now implies all; if no

Re: RFR 8168979: @implNote for invalid FilePermission

Webrev updated at http://cr.openjdk.java.net/~weijun/8168979/webrev.01 One comment is moved to its correct position and a typo fixed. Thanks Daniel for the comment. Can someone with a reviewer hat take a look? Thanks Max > On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote: > > Hi Max, > >

Re: RFR: jsr166 jdk9 integration wave 13

Working my way through it… One general question: why did you replace Arrays.fill with an explicit loop in many cases? Paul. > On 13 Dec 2016, at 15:13, Martin Buchholz wrote: > > We were supposed to be winding down jdk9, and there are a lot of changes > here, but ... it would be a shame not

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

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 (esp. the crazily large XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). http://cr.openjdk.java.net/~jo

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

Hi Aleksej, You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) wh

RFR: jsr166 jdk9 integration wave 13

We were supposed to be winding down jdk9, and there are a lot of changes here, but ... it would be a shame not to have fast specialized implementations for new collection methods added in Java 8. There's also a fix for a serious bug in LinkedBlockingQueue. http://cr.openjdk.java.net/~martin/webre

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

Hello, Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block: http://cr.openjdk.java.net/~aefimov/8146271/9/00/ Best Regards, Al

RFR: 8169806 - DriverManager javadoc clarifications

Hi all, This review request addresses some a cleanup to the DriverManager javadocs. The CCC for the changes has been approved. The webrev can be found at http://cr.openjdk.java.net/~lancea/8169806/webrev.03/ Best, Lance

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

Hi Christoph, For the test, yes, please add an unit test based on the test submitted, sanitize / remove any private information in the original test where necessary. Best regards, Joe On 12/13/16, 12:31 PM, Langer, Christoph wrote: Hi, this is the fix for the regression introduced with 81

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

Hi Joe, looks nice, thanks for doing that. Here are a few findings: src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java: -> import statements could be ordered alphabetically 262 fEntityScanner = fEntityManager.getEntityScanner() ; -> spaces before

Re: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

+1 Naoto On 12/13/16 6:34 AM, Roger Riggs wrote: Hi Masayoshi, looks fine; (without the javadoc) Roger On 12/13/2016 8:24 AM, Stephen Colebourne wrote: The overridden method includes full Javadoc and an @since 9 tag. I believe that this Javadoc should not be present and the @since tag is

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

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 (FileChannel fc = FileChannel.open(Paths.get("bob"), CREATE, WRITE)) { 2. badBuffers could include a duplicate and a slice of a direct

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

Hi, +1 to this approach. I can create a PR for Apache Lucene to test this! With our current code it is very easy to add support for this - which is great (at the end I just need a MethodHandle with a MethodType "(ByteBuffer)void")! Unfortunately I am not good in compiling OpenJDK, so if somebo

Re: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint

Thank you, Mandy and Daniel. As a point of interest, automated testing uncovered a couple things I had to change before pushing: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/accf1676e416 * Updated the CHECK_OFFSET line, so fastdebug builds http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ddc8f

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

Hi, this is the fix for the regression introduced with 8150704. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169112.0/ The problem occurs during "outlining" of a translet method. Outlining happens when the size of byte

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

Taking into account the feedback so far, and changing the method name ( since it is an attractive nuisance ), here is where I think we ended up. http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ If this is agreeable, I’ll file an issue in JIRA to track the code changes, and update JEP 26

RFR 8171179: Problem list LFSingleThreadCachingTest.java until JDK-8171149 is fixed

Hi All, The test java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java is failing on tier 1 platforms. UntilJDK-8171149 is fixed, the test should be problem listed. Please review the patch below: diff -r 6f76a77638cb test/ProblemList.txt

Re: RFR of JDK-8171076: improve rmi tests by replacing TestLibrary.createRegistryOnUnusedPort, getUnusedRandomPort

Hi Hamlin, Looks fine. Thanks, Roger On 12/13/2016 12:11 AM, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171076 webrev: http://cr.openjdk.java.net/~mli/8171076/webrev.00/ There are rmi tests using TestLibrary.createRegistryOnUnus

Re: RFR of JDK-8171072: java/rmi/transport/handshake*/Handshake*.java, exception is not thrown when reach failure test case

Hi Hamlin, Sorry for the delay. Looks fine. Roger On 12/13/2016 12:19 AM, Hamlin Li wrote: Is some one available to review the patch? Thank you -Hamlin On 2016/12/12 16:48, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171072 web

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 fal

Hi all Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is for JDK-8087303 and JDK-8114834, I have to combine the fix because there is some interaction between them. Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 https://bugs.openjdk.java.net/browse/JDK-8114834 Besi

Re: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

Hi Masayoshi, looks fine; (without the javadoc) Roger On 12/13/2016 8:24 AM, Stephen Colebourne wrote: The overridden method includes full Javadoc and an @since 9 tag. I believe that this Javadoc should not be present and the @since tag is wrong. Stephen On 11 December 2016 at 02:26, Masa

Re: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

The overridden method includes full Javadoc and an @since 9 tag. I believe that this Javadoc should not be present and the @since tag is wrong. Stephen On 11 December 2016 at 02:26, Masayoshi Okutsu wrote: > Thank you for the review comments. I realized that only TextStyle.NARROW and > NARROW_S

Re: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently

Hi Peter, This is a bold proposal, I would be frightened to touch at this code :-) Good observations about the simplifications induced by taking the caller's module as part of the cache key (in particular getting rid of RBClassLoader.INSTANCE). I have imported your patch (had to fight a bit bec