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

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

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:

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

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

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]

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,

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:

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

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 since

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

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 <huizhe.w...@oracle.com <mailto:huizhe.w...@oracle.com>> wr

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:

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

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

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 <huizhe.w...@oracle.com <mailto:huizhe.w...@oracle.com>> wrote: Hi, Removing an implementation detail from the javadoc of SAXSource, please review:

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

uot; + 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 release bundle with the following excep

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

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 <huizhe.w...@oracle.com <mailto:huizhe.w...@oracle.com>> wrote: Please review the change to remove the incorrectly added @Deprecated annotation. The webrevs

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:

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

uggestion 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'm new to acc

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

traintValue(); } cheers, -- daniel On 08/07/2017 01:53, huizhe wang wrote: Here's the updated webrev: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev01/ <http://cr.openjdk.java.net/%7Ejoehw/jdk10/8181154/webrev01/> Thanks, Joe On 7/7/2017 10:59 AM, huizhe wang wrot

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

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 CatalogFeatures, the id

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 -

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

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

and 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 <huizhe.w...@oracle.com> wrote: On 6/14/2017 4:58 PM, Mandy Chung wrote: On Jun 14, 2017, at 4:19 PM, huizhe wang <

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 <huizhe.w...@oracle.com> 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 r

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

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 <huizhe.w...@oracle.com <mailto:huizhe.w...@oracle.com>> wrote: Hi, This change fixes dep-ann warnings. (1) For most cases,

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

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

he 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: https://

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

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

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

er than TODO), but the new copyright year is now 20017. ;-) Thanks, Brian On May 9, 2017, at 3:15 PM, huizhe wang <huizhe.w...@oracle.com <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

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

, huizhe wang <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 to package-info.java. JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 webrevs

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:

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

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

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

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

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 testResetEnabled

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

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,

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 <huizhe.w...@oracle.com <mailto:hu

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

d 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/ Thanks, Joe

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 <huizhe.w...@oracle.com> wrote: In a jigsaw changeset [1], configuration file

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

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

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 <huizhe.w...@oracle.com <mailto:huizhe.w...@oracle.com>> wrote: Thanks Lance. Updated. http://cr.openjdk.java.net/~joehw/jdk9/81

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

, 2017, at 1:36 PM, huizhe wang <huizhe.w...@oracle.com <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.o

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

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

s and best regards Christoph *From:*Langer, Christoph *Sent:* Montag, 13. Februar 2017 16:15 *To:* 'huizhe wang' <huizhe.w...@oracle.com> *Cc:* core-libs-dev@openjdk.java.net; Aleksej Efimov <aleksej.efi...@oracle.com> *Subject:* RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element genera

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]

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

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), which

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

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: huizhe wang

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 <daniel.fu...@oracle.com <mailto:daniel.fu...@oracle.com>> wrote: On 14/02/17 17:21, huizhe wang wrote: Thanks! Here's an updated

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

/ 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 JDK-8087303 Note that the bug id was incorrect, it should have been 8174025. 8170192 was a test bug

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 wang

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

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.openjdk.java.net/browse/JDK

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

[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. This is one

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/

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' <huizhe.w...@oracle.com> Cc

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

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

/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'<huizhe.w...@oracle.com>; core-libs-dev@openjdk.java.net S

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

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,

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:

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 ma

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

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 introduced

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 introduced

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

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

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

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:

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) 8158084: Catalog API: JAXP XML Processor Support

...@openjdk.java.net] On Behalf Of huizhe wang Sent: Montag, 25. Juli 2016 06:45 To: core-libs-dev <core-libs-dev@openjdk.java.net> 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 proc

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

Re: [8u-dev] RFR (JAXP) 8028363: XmlGregorianCalendarImpl.getTimeZone() bug when offset is less than 10 minutes

+1. -Joe On 7/21/2016 10:40 AM, Seán Coffey wrote: Looks fine to me also Svetlana. Regards, Sean. On 21/07/2016 13:13, Svetlana Nikandrova wrote: Little reminder. On 19.07.2016 19:29, Svetlana Nikandrova wrote: Hello, please review this fix for 8u-dev. For jdk9 problem has been

Re: [JAXP] RFR: 8153082: Update XSTL compiler to generate classes that invoke addReads

On 7/22/2016 11:57 PM, Alan Bateman wrote: On 22/07/2016 17:16, Daniel Fuchs wrote: Hi, Please find below a fix for 8153082: Update XSTL compiler to generate classes that invoke addReads https://bugs.openjdk.java.net/browse/JDK-8153082 This fix removes a dependency from java.xml to an

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

le one. -Joe On 7/21/2016 9:25 AM, huizhe wang wrote: Hi Svetlana, It would be good to apply the same format to these get* methods. Please see below. @@ -510,16 +510,16 @@ * @see #getYear() */ public abstract BigInteger getEonAndYear(); /** - * Re

  1   2   3   4   5   6   >