Re: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

On 7/12/20 11:11 PM, Alan Bateman wrote: On 12/07/2020 23:21, Joe Wang wrote: Hi all, Alan updated the bug to indicate it fails since JDK 9. Given we still have a couple days for JDK 15, I've rebased the patch to the jdk15 repo and would like to check in the patch into JDK 15 instead (and

Re: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

Thanks Chris, Roger, and Mandy.  I've updated the webrev using AtomicInteger and removing java.base export. Here's the updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/ -Joe On 7/10/20 9:59 AM, Mandy Chung wrote: Hi Joe, The change looks good.   You can consider using

RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

Hi, Please review a patch to remove an illegal access to java.lang by the SafeThread. Note that InnocuousThread meets all the needs for SafeThread except that it also revokes permissions that the xml parser requires. This patch uses the new constructor added to Thread in JDK 9 that do not inh

Re: RFR [15/java.xml] 8248884: Regression caused by the update to BCEL 6.0

On 7/6/20 4:55 PM, Stuart Marks wrote: On 7/6/20 4:37 PM, huizhe.w...@oracle.com wrote: Please refer to the previous review for 8248348. This patch should have been pushed into 15 in the first place. I hope a merge with 16 repo won't cause any trouble/conflict. JBS: https://bugs.openjdk.j

RFR [15/java.xml] 8248884: Regression caused by the update to BCEL 6.0

Please refer to the previous review for 8248348. This patch should have been pushed into 15 in the first place. I hope a merge with 16 repo won't cause any trouble/conflict. JBS: https://bugs.openjdk.java.net/browse/JDK-8248884 webrev: http://cr.openjdk.java.net/~joehw/jdk15/8248884/webrev/

Re: RFR (JDK11/JAXP) 8193830: Xalan Update: Xalan Java 2.7.2

Thanks Lance! The russian and polish files were the original ones submitted by the bug reporter. I double-checked with this https://en.wikipedia.org/wiki/Russian_alphabet :-) -Joe On 2/1/2018 12:06 PM, Lance Andersen wrote: Hi Joe, Changes look fine.  I assume the russian and polish is cor

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks Sherman.  Found it now.  Interesting method. What was the motivation? Does any class implement CharSequence in 310? Best, Joe On 1/26/2018 2:12 PM, Xueming Shen wrote: java.time.format.DateTimeParseContext.subSequenceEquals On 1/26/18, 1:48 PM, huizhe wang wrote: Thanks Stephen for

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks Stephen for the note. I downloaded the api [1], but don't seem to see a class "DateTimeParseContext". Do you have a pointer to the current webrev? What does it do, and what would be the implication with regards to the CharSequence compare method? [1] https://jcp.org/en/jsr/detail?id=3

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks for the comments, Jason. The topic about equals/hashcode had been discussed. They are currently inherited, and by definition of CharSequence, equality is generally undefined. One could argue for it to be a lexicographic comparison, but that means changing the current specification, pote

Re: RFR (JDK10/JAXP Doc-only) 8181047: Add comment to technical terms that shall not be translated

Maybe you should also add a comment for this line:  NoCatalogFound = JAXP09030003: No Catalog is specified. Thanks, Leo On 01/13/2018 03:40 AM, huizhe wang wrote: Hi, Please review a doc-only change that adds a few notes to message files that serves as a notification to translation teams

RFR (JDK10/JAXP Doc-only) 8181047: Add comment to technical terms that shall not be translated

Hi, Please review a doc-only change that adds a few notes to message files that serves as a notification to translation teams that some technical terms shall not be translated. JBS: https://bugs.openjdk.java.net/browse/JDK-8181047 webres: http://cr.openjdk.java.net/~joehw/jdk10/8181047/webrev

Re: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

Thanks Joe! Cheers, Joe On 1/3/2018 4:47 PM, Joseph D. Darcy wrote: Looks fine Joe; cheers, -Joe On 1/3/2018 3:32 PM, huizhe wang wrote: Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed since the reference(s) to the Errata is part of

Re: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

rated in the current specification that the link to "Namespaces in XML" points to, there's no more reason to link to the Errata. Thanks, Joe On 1/3/2018 3:32 PM, huizhe wang wrote: Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed s

RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed since the reference(s) to the Errata is part of the Namespaces in XML specification itself. There is no need for the extra link(s).  Also, for NamespaceContext, the link to "Namespaces in XM

Re: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few Deprecation warrnings and enable -Xlint:all

Thanks for reviewing! For the last modified part, we can discuss updating the header script offline. Many of the classes have already used this format, I hope you're okay with me checking in this changeset. Thanks, Joe On 11/28/2017 10:19 AM, joe darcy wrote: Hi Joe, The code changes look

Re: RFR (JDK10/JAXP) 8191161: Reconsider generification of XPathFunction.evaluate

Thanks Lance, Roger!  Yep, it appeared that html formatting was only good in my mail editor. -Joe On 11/16/2017 11:00 AM, Lance Andersen wrote: Hi Joe, Yes  List  makes sense On Nov 16, 2017, at 1:51 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: https://bugs.openjdk

RFR (JDK10/JAXP) 8191161: Reconsider generification of XPathFunction.evaluate

Hi, Please review a quick catch-up fix on 8181150: the raw type List was changed to List when it would have been more favorable if  it was List: src/java.xml/share/classes/javax/xml/xpath/XPathFunction.java |- public Object evaluate(List args) + public Object evaluate(List args) JBS: https

Re: JDK-8190919 :StaX buffers do not really close underlying buffers

Hi Srividya, There had been for and against XMLStreamWriter/Reader closing the underlying stream, about 10 years ago, both had use cases. There is a legitimate argument that the XML writer/reader shall be consistent with java.io. Unfortunately, the later (not closing) won because that's indee

Re: RFR (JDK10/JAXP) 8181151: Fix lint warnings in JAXP repo: cast

Thanks Lance, Roger!  After this, will do a final check, a few JDK 9 deprecations, we'll be completely free from warnings! -Joe On 11/7/2017 12:04 PM, Roger Riggs wrote: +1 On 11/7/2017 2:47 PM, Lance Andersen wrote: Looks OK Joe On Nov 7, 2017, at 2:12 PM, Joe Wang wrote: Hi, This chang

Re: RFR(jdk10/jaxp) 8186675: Javadoc of SAXSource contains implementation detail

Thanks Lance! Joe On 8/25/2017 3:49 AM, Lance Andersen wrote: +1 On Aug 24, 2017, at 9:26 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Removing an implementation detail from the javadoc of SAXSource, please review: JBS: https://bugs.openjdk.java.net/browse/JD

RFR(jdk10/jaxp) 8186675: Javadoc of SAXSource contains implementation detail

Hi, Removing an implementation detail from the javadoc of SAXSource, please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8186675 webrev: http://cr.openjdk.java.net/~joehw/jdk10/8186675/webrev/ Thanks, Joe

Re: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release

Thanks Daniel! Best regards, Joe On 8/11/2017 3:31 AM, Daniel Fuchs wrote: Hi Joe, Thanks, looks fine now! best regards, -- daniel On 10/08/2017 04:13, huizhe wang wrote: On 8/9/2017 6:30 AM, Daniel Fuchs wrote: Hi Joe, This not an easy patch to review ;-) Indeed, took several

Re: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release

Thanks Frank for looking into and verifying the relevant tests. We have a rich set of tests that have been very helpful with this update. I've addressed a number of failures during the work, but it's true that Bug8003147Test never failed. Best regards, Joe On 8/11/2017 1:08 AM, Frank Yuan wr

Re: RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release

uot;Could not load any resource bundle by " + bundle, bundle, ""); 259 } 260 } 261 }); 262 } best regards, -- daniel On 09/08/2017 00:43, huizhe wang wrote: Please review an update to BCEL release 6.0 [1]. The sources are basically that from the re

RFR(jdk10/jaxp) 8163121: BCEL: update to the latest 6.0 release

Please review an update to BCEL release 6.0 [1]. The sources are basically that from the release bundle with the following exceptions: * Classes that were not included in the original version are excluded; * Classes that are deprecated in BCEL 6.0 are removed; * Classes that are used only f

Re: RFR: JDK-8185464: Link issues in java.xml module

Looks good to me too. A side issue, the 'fixedNav' block is preventing the browser from showing the exact content of an inner anchor, the Nav section covers that much of content as its height. If I click on the link to CatalogFeatures.html#PREFER for example, I'd get to see DEFER. Best, Joe

Re: RFR(jdk10/jaxp) 8183519: XMLInputFactory.newFactory() is marked as deprecated

Thanks Lance! On 7/17/2017 1:46 PM, Lance Andersen wrote: looks fine joe On Jul 17, 2017, at 4:40 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: Please review the change to remove the incorrectly added @Deprecated annotation. The webrevs are the same as the specification o

RFR(jdk10/jaxp) 8183519: XMLInputFactory.newFactory() is marked as deprecated

Please review the change to remove the incorrectly added @Deprecated annotation. The webrevs are the same as the specification of the CSR (https://bugs.openjdk.java.net/browse/JDK-8183894). JBS: https://bugs.openjdk.java.net/browse/JDK-8183519 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/81

Re: RFR: 8184021: Fix tables in jaxp doc comments to be accessible

feedback and suggestion to revisit this issue. -- Jon On 7/7/17 5:50 PM, huizhe wang wrote: Hi Jon, For the table in CatalogFeatures, the id attribute for Type and Value are not used, may be unnecessary. Instead, scope="col" can be added, is that right? 50 * Type 51 * Value I&#

Re: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation

/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java 2017-07-07 21:15:05.077746257 -0700 [...] +@SuppressWarnings("deprecation") public String getSchemaDefault() { return fDeclaration == null ? null : fDeclaration.getConstraintValue();

Re: RFR: 8184021: Fix tables in jaxp doc comments to be accessible

some experiments and it looks like we can indeed simplify the more complex tables to always use scope=row|col. I'll post an amended webrev next week. Thanks for the feedback and suggestion to revisit this issue. -- Jon On 7/7/17 5:50 PM, huizhe wang wrote: Hi Jon, For the table in CatalogFeatur

Re: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation

Here's the updated webrev: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev01/ Thanks, Joe On 7/7/2017 10:59 AM, huizhe wang wrote: #11 com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java 1166 final public void setYear(BigInteger year) { nit

Re: RFR: 8184021: Fix tables in jaxp doc comments to be accessible

Hi Jon, For the table in CatalogFeatures, the id attribute for Type and Value are not used, may be unnecessary. Instead, scope="col" can be added, is that right? 50 * Type 51 * Value I'm new to accessibility, but it seems to me the following can use scope="colgroup" instead? 46 * Value [

Re: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation

#11 com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java 1166 final public void setYear(BigInteger year) { nit: for consistency you should reorder the keywords to: public final void same file: - BigInteger.valueOf((long) 1) => BigInteger.ONE - new

RFR(jdk10/jaxp) 8177561: Remove deprecated for removal portions of com.sun.org.apache

Hi, Please review the removal of the internal Catalog packages: JBS: https://bugs.openjdk.java.net/browse/JDK-8177561 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8177561/webrev/ Thanks, Joe

Re: RFR(JAXP) 8182111: Package summary is missing in jdk.xml.dom module

1.0, W3C Working Group Note 26 February 2004 except that the values of XPathException.INVALID_EXPRESSION_ERR and XPathException.TYPE_ERR are 1 and 2 respectively (instead of 51 and 52). Best, Joe On 6/15/2017 11:52 AM, Mandy Chung wrote: On Jun 15, 2017, at 10:28 AM, huizhe wang wrote: Hi

Re: RFR(JAXP) 8182111: Package summary is missing in jdk.xml.dom module

the latest. http://cr.openjdk.java.net/~joehw/jdk9/8182111/webrev02/ Thanks, Joe On 6/14/2017 9:57 PM, Mandy Chung wrote: On Jun 14, 2017, at 9:29 PM, huizhe wang wrote: On 6/14/2017 4:58 PM, Mandy Chung wrote: On Jun 14, 2017, at 4:19 PM, huizhe wang wrote: Hi, Please review new package

Re: RFR(JAXP) 8182111: Package summary is missing in jdk.xml.dom module

On 6/14/2017 4:58 PM, Mandy Chung wrote: On Jun 14, 2017, at 4:19 PM, huizhe wang wrote: Hi, Please review new package descriptions for jdk.xml.dom module. Note that the link to the XPath specificaiton in xpath/package-info.java is the formal release that is different from the one in the

RFR(JAXP) 8182111: Package summary is missing in jdk.xml.dom module

Hi, Please review new package descriptions for jdk.xml.dom module. Note that the link to the XPath specificaiton in xpath/package-info.java is the formal release that is different from the one in the classes. The later was a working release now requires a login [1]. The only difference in the

Re: RFR(JDK10/JAXP): 8181153: Fix lint warnings in JAXP repo: dep-ann

Thanks Lance! Pushed. -Joe On 6/14/2017 1:22 PM, Lance Andersen wrote: Hi Joe, Looks fine. Best Lance On Jun 14, 2017, at 1:44 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, This change fixes dep-ann warnings. (1) For most cases, @Deprecated is simply added

RFR(JDK10/JAXP): 8181153: Fix lint warnings in JAXP repo: dep-ann

Hi, This change fixes dep-ann warnings. (1) For most cases, @Deprecated is simply added below the @deprecated javadoc tag and above the relevant class or method. (2) For XSLTErrorResources*.java, unused constants are removed. (3) DOM2Helper.java The original DOM2Helper was deprecated and

Re: RFR 8180349: Review JAXP Java SE 9 API javadocs

cover the topic in details with sample code in the developer guide. Here's updated webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev01/ Thanks, Joe Thanks, Roger On 5/23/2017 1:01 PM, huizhe wang wrote: Hi, Please review an update to the JAXP Java SE 9 API javadocs. JBS

RFR 8180349: Review JAXP Java SE 9 API javadocs

Hi, Please review an update to the JAXP Java SE 9 API javadocs. JBS: https://bugs.openjdk.java.net/browse/JDK-8180349 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev/ There's a lot of format changes while converting to package-info.java, but only minor (wording) changes to the o

Re: RFR: 8180728: DatabaseMeta.getRowIdLifetime returns an enum but javadoc refers to int

+1 -Joe On 5/23/2017 6:56 AM, Roger Riggs wrote: Hi Lance, Should one of those @code's be @link so it is easy to get to the ROWID javadoc? Otherwise, looks fine, Roger On 5/23/2017 7:21 AM, Lance Andersen wrote: Hi all, This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0

Re: RFR: 8180385: fix HTML issues in java.xml module

Hi Jon, Looks good. Thanks again! -Joe On 5/16/2017 3:27 PM, Jonathan Gibbons wrote: Please review these fixes to update the public doc comments in the java.xml module for HTML 5. Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/ API: http://cr.openjdk.java.net/~jjg/8180385/api.02/

Re: RFR(S): 8180195: remove jaxp testlibrary

+1. Thanks Frank for checking. -Joe On 5/15/2017 7:50 PM, Frank Yuan wrote: Looks fine, although I am not a reviewer. Thanks Frank -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Igor Ignatyev Subject: RFR(S): 8180195: remove jaxp

Re: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs

is now 20017. ;-) Thanks, Brian On May 9, 2017, at 3:15 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting

Re: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs

, huizhe wang wrote: Hi, Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting to package-info.java. JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 webrevs: http://cr.openjdk.jav

RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs

Hi, Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting to package-info.java. JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/

RFR (JAXP) 8150256: removing xerces-related dead code

Hi, Please review removing three unused classes from the jaxp repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8150256 Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/ Tests: passed Refer to the jaxp change history [1], the following changes in particular: - - protected XPoint

Re: RFR 8179634: Add JDBC 4.2 to bullet list in package.html

+1 Joe On 5/4/2017 10:40 AM, Lance Andersen wrote: Hi, This RFR is for a trivial update to package.html to include 4.2 which was accidentally omitted — hg diff package.html diff -r a50b619ac159 src/java.sql/share/classes/java/sql/package.html --- a/src/java.sql/share/classes/java/sql

Re: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism

Hi Lance, In DriverManagerModuleTests, at line 83, did you mean to assign the result of DM::getDriver to d2 although an Exception is expected? Otherwise, the patch looks good to me. Best, Joe On 5/2/2017 11:33 AM, Lance Andersen wrote: Hi all, The above issue adds a test to verify that

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

+1 Joe On 4/27/2017 12:08 PM, Brent Christian wrote: Hi, This test times out under our automated testing configurations that include -Xcomp. Please review my change to increase the timeout for this test. It is sufficient for the test configurations in question to pass on two different lo

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

es. Best Regards, Aleksei [1] http://cr.openjdk.java.net/~aefimov/8176168/01/ On 19/04/17 21:41, huizhe wang wrote: Hi Aleksej, The changes look good. Some changes to the notes in the test may make it a bit clearer on what scenarios are tested: move the current notes for the method testReset

Re: RFR 8178915: Minor update to the PooledConnection javadoc

Hi Lance, The changes look good to me. -Joe On 4/20/2017 6:40 AM, Lance Andersen wrote: Hi all, This RFR makes a minor update to the PooledConnection javadoc. The CCC has been approved. Here is the diff: ——— $ hg diff diff -r 9ba6760481a8 src/java.sql/share/classes/javax/sql/PooledCon

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

Hi Aleksej, The changes look good. Some changes to the notes in the test may make it a bit clearer on what scenarios are tested: move the current notes for the method testResetEnabled to parseAndCheckReset, and then add scenario description to the three test* methods, for example, testNoFeatur

Re: RFR (JAXP) 8176405 : Catalog circular reference check did not work in certain scenarios

Thanks Roger, Lance! Re-running tests, I'll push the patch once they pass. -Joe On 3/23/2017 1:59 PM, Lance Andersen wrote: Hi Joe, The current version, including our offline discussion, looks good. On Mar 17, 2017, at 4:22 PM, huizhe wang <mailto:huizhe.w...@oracle.com>&g

Re: RFR (JAXP) 8176405 : Catalog circular reference check did not work in certain scenarios

ted if the test succeeds, so is of little value Changed that to assertTrue(msg.contains(expectedMsgId)). It's safer, in case the test is run on a non-English system. Updated: JBS: https://bugs.openjdk.java.net/browse/JDK-8176405 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8176405/webrev/

Re: RFR (JAXP) 8177350: Two missed in the change from ${java.home}/lib to ${java.home}/conf

Thanks Mandy, Lance! I added jdk9-fix-request as per the RDP2 Process. Will push once it's approved. -Joe On 3/21/2017 12:27 PM, Mandy Chung wrote: +1 Mandy On Mar 21, 2017, at 11:58 AM, huizhe wang wrote: In a jigsaw changeset [1], configuration files were moved from ${java.home

RFR (JAXP) 8177350: Two missed in the change from ${java.home}/lib to ${java.home}/conf

In a jigsaw changeset [1], configuration files were moved from ${java.home}/lib directory to ${java.home}/conf. However, I found two misses as I searched the jaxp repo. javax/xml/stream/FactoryFinder.java: There were two references to the "lib" directories. The one for jaxp.properties was rep

RFR (JAXP) 8176405 : Catalog circular reference check did not work in certain scenarios

Hi, Please review a fix to the circular reference check that incorrectly treated duplicate entries as circular. JBS: https://bugs.openjdk.java.net/browse/JDK-8176405 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8176405/webrev/ Thanks, Joe

Re: RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Thanks Roger, Joe! -Joe On 3/14/2017 6:16 PM, Roger Riggs wrote: Looks fine Joe. On 3/14/17 9:08 PM, huizhe wang wrote: Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/

RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java b/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java --- a/src/java.xml/share/classes/javax/xml/stream/X

Re: RFR (JAXP) 8175830: Provide javadoc description for jdk.xml.dom module

Pushed. Thanks again Lance! -Joe On 3/7/2017 10:59 AM, Lance Andersen wrote: I think you are good to go Joe On Mar 7, 2017, at 1:56 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: Thanks Lance. Updated. http://cr.openjdk.java.net/~joehw/jdk9/8175830/webrev/src/jdk.xml.

Re: RFR (JAXP) 8175830: Provide javadoc description for jdk.xml.dom module

, 2017, at 1:36 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a module description for jdk.xml.dom. JBS: https://bugs.openjdk.java.net/browse/JDK-8175830 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8175830/webrev/ <http://cr.openjdk.java.net/%7Ejoehw/

RFR (JAXP) 8175830: Provide javadoc description for jdk.xml.dom module

Hi, Please review a module description for jdk.xml.dom. JBS: https://bugs.openjdk.java.net/browse/JDK-8175830 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8175830/webrev/ Thanks, Joe

Re: RFR JDK-8176235: Minor updates to package.html

Hi Lance, Looks good. best, Joe On 3/6/2017 12:34 PM, Lance Andersen wrote: Hi all, This RFR is for minor updates to package.html for JDBC. For JDK 10, I will probably overhaul these files and possibly convert to package-info.java. But for now just keeping the updates minimal. Best Lanc

Re: [10] RFR: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

g. Thanks and best regards Christoph *From:*Langer, Christoph *Sent:* Montag, 13. Februar 2017 16:15 *To:* 'huizhe wang' *Cc:* core-libs-dev@openjdk.java.net; Aleksej Efimov *Subject:* RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given

Re: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing across platforms

+1. Yes, specific permission is desirable. Thanks for the quick fix! -Joe On 2/16/2017 5:36 AM, Frank Yuan wrote: Since no one has more comment, and Joe agree this solution, I will push the change. Thanks Frank -Original Message- From: Weijun Wang [mailto:weijun.w...@oracle.com] Se

Re: [9] RFR: 8173390: Investigate SymbolTable in SAXParser

se of failure. Because of that I removed the sout.println's from the test too. With Best Regards, Aleksej On 15/02/17 20:16, huizhe wang wrote: Hi Aleksej, I just realized there were other dependencies on the SymbolTable instance initialized in the constructor (line 575 in your new code),

Re: [9] RFR: 8173390: Investigate SymbolTable in SAXParser

Hi Aleksej, I just realized there were other dependencies on the SymbolTable instance initialized in the constructor (line 575 in your new code), which was probably why you kept the code from 574 through 579 after adding new SymbolTable for each parsing process (850 - 854). As a result, the S

Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303

stated in previous mail is made: http://cr.openjdk.java.net/~fyuan/8174025/webrev.02/ Thanks Frank -Original Message- From: Frank Yuan [mailto:frank.y...@oracle.com] Subject: RE: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303 -Original Message----- From: h

Re: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

Thanks Lance, Daniel! -Joe On 2/14/2017 10:53 AM, Lance Andersen wrote: Looks good… ship it. On Feb 14, 2017, at 1:41 PM, Daniel Fuchs <mailto:daniel.fu...@oracle.com>> wrote: On 14/02/17 17:21, huizhe wang wrote: Thanks! Here's an updated webrev: http://cr.openjdk.java.n

Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303

, ignore it/them. Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/ Thanks Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by J

Re: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

Thanks! Here's an updated webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/ -Joe On 2/14/2017 4:07 AM, Lance Andersen wrote: Looks good overall Joe. I would agree that I would clean up the minor comment alignment issues. Best Lance On Feb 13, 2017, at 9:27 PM, huizhe

Re: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

le of test cases to cover this. Best, Joe best regards, -- daniel On 14/02/17 02:27, huizhe wang wrote: A quick fix for the error parsing xml declaration. This is one of the three outstanding issues in the xml area that must be addressed for the coming development deadline. JBS: https://bugs.op

Re: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of huizhe wang Sent: Dienstag, 14. Februar 2017 03:28 To: core-libs-dev@openjdk.java.net Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration A quick fix for the error parsing xml declaration

RFR (JAXP) 8169450: StAX parse error if there is a newline in xml declaration

A quick fix for the error parsing xml declaration. This is one of the three outstanding issues in the xml area that must be addressed for the coming development deadline. JBS: https://bugs.openjdk.java.net/browse/JDK-8169450 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/ Checki

Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

On 2/13/2017 11:21 AM, huizhe wang wrote: Hi Christoph, The negatives were actually across all platforms, although the benchmark system picked up that it thinks were significant (high probability of a regression). There were negatives numbers that were bigger than the two. One

Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

://cr.openjdk.java.net/~clanger/webrevs/8172974.1-SAX2DTM2only/ I'd really be interested in the performance results for that one before I turn to JDK10. Thanks Christoph -Original Message- From: Langer, Christoph Sent: Samstag, 11. Februar 2017 15:50 To: 'huizhe wang' Cc: core-libs-dev@o

should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303

Note that the bug id was incorrect, it should have been 8174025. 8170192 was a test bug fix. -Joe On 2/13/2017 1:35 AM, Frank Yuan wrote: Hi Joe and Daniel Thank you very much for your review! Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent

Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303

+1 from me too. Thanks, Joe On 2/10/2017 5:25 AM, Daniel Fuchs wrote: Hi Frank, Thanks for fixing this! I imported your patch and played with it a bit. Also ran the jaxp test. Both issues reported have indeed disappeared. So that's a +1 from me. best regards, -- daniel On 10/02/17 11:03,

Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

merely cleanups apart from com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startElement(), which to me seem natural after 8169631, though. Thanks, Christoph -Original Message- From: Langer, Christoph Sent: Mittwoch, 18. Januar 2017 22:55 To: 'huizhe wang'; core-libs-de

Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

On 2/7/2017 11:28 PM, Langer, Christoph wrote: Hi Joe, welcome back. Thanks! This sounds reasonable. I’ll prepare a change for JDK10. Hopefully it'd open soon so that you don't have to keep it for too long. Best, Joe Thanks Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com]

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

Hi Christoph, Refer to the previous email, I know we discussed your customer's need to process legacy sources. However, Xalan inherently requires namespace aware. I also don't think adding a SAX feature to the Transform API is appropriate. Thanks, Joe On 1/18/2017 8:44 AM, Langer, Christoph

Re: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace unaware StAX Input

Hi Christoph, Xalan requires the underlying parser to be namespace aware. Please refer to https://xml.apache.org/xalan-j/faq.html#faq-N10207 Thanks, Joe On 1/18/2017 8:26 AM, Langer, Christoph wrote: Hi, please review a change for JAXP. Bug: https://bugs.openjdk.java.net/browse/JDK-8172974

Re: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws FileSystemNotFoundException with jar

Thanks Roger! -Joe On 1/11/2017 10:38 AM, Roger Riggs wrote: Hi Joe, Thanks for the clarifications. Looks good Roger On 1/10/2017 1:58 PM, huizhe wang wrote: On 1/9/2017 2:17 PM, Roger Riggs wrote: Hi Joe, a few comments: CatalogManager: - line 58: "will /return /as no mappi

Re: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws FileSystemNotFoundException with jar

Looks good, Roger On 1/9/2017 12:38 PM, huizhe wang wrote: Hi, The current Catalog API accepts file paths or URIs in a form of String to create Catalog or CatalogResolver in an effort to maintain consistency with the old Catalog API and other existing processors. However, that also introduc

Re: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws FileSystemNotFoundException with jar

Joe Looks good, Roger On 1/9/2017 12:38 PM, huizhe wang wrote: Hi, The current Catalog API accepts file paths or URIs in a form of String to create Catalog or CatalogResolver in an effort to maintain consistency with the old Catalog API and other existing processors. However, that also introduc

Re: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws FileSystemNotFoundException with jar

e top interfaces requires that the URIs must be absolute, they can prevent relative URIs from happening in a catalog file, which is allowed by the Catalog Standard. Best, Joe best regards, -- daniel On 09/01/17 17:38, huizhe wang wrote: Hi, The current Catalog API accepts file paths or URIs

RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws FileSystemNotFoundException with jar

Hi, The current Catalog API accepts file paths or URIs in a form of String to create Catalog or CatalogResolver in an effort to maintain consistency with the old Catalog API and other existing processors. However, that also introduced an ambiguity in the API, which is unwanted for a new API i

Re: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here?

with regards to such null data. Especially given that it’s possible via the DOM API to construct such null nodes. So I take you support this endeavor? Sure. Some null-checks are welcome. Thanks, Joe Thanks Christoph *From:*huizhe wang [mailto:huizhe.w...@oracle.com] *Sent:* Dienstag, 8

Re: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here?

Looks like a null check-in is desirable. If the intention is to add a text node, which I assume was his intention, he wouldn't want a null node. If the intention is to create an empty element, then he didn't need the line that added the null text node. As far as DOM goes, it would have been be

Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Christoph, On 7/28/2016 6:10 AM, Langer, Christoph wrote: Hi, please review my change for the XSLT namespace issue. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162598.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-816

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">

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

On 7/25/2016 2:46 AM, Frank Yuan wrote: -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests On 7/22/2016 5:53 AM, Daniel Fuchs wrote: On 22/07/16 10:15, Frank Yuan wrote: Hi Daniel

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

eturns and @return. Hope now it looks better and more consistent: http://cr.openjdk.java.net/~snikandrova/8021787/webrev.02/ <http://cr.openjdk.java.net/%7Esnikandrova/8021787/webrev.02/> Thank you, Svetlana On 21.07.2016 19:32, huizhe wang wrote: The editor of the new version of Thun

Re: RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support

-boun...@openjdk.java.net] On Behalf Of huizhe wang Sent: Montag, 25. Juli 2016 06:45 To: core-libs-dev Subject: RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support Hi, This is an enhancement to support the Catalog API (javax.xml.catalog) throughout the JAXP processors. All of the CatalogFeature

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

On 7/22/2016 5:53 AM, Daniel Fuchs wrote: On 22/07/16 10:15, Frank Yuan wrote: Hi Daniel Thank you very much for your review and the comments! -Original Message- From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP

RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support

Hi, This is an enhancement to support the Catalog API (javax.xml.catalog) throughout the JAXP processors. All of the CatalogFeatures are supported by the JAXP factories and processors (e.g. SAXParser), and corresponding System properties as specified in the CatalogFeatures. An additional java

  1   2   3   4   5   6   >