On 11/4/2013 12:38 AM, Alan Bateman wrote:
On 31/10/2013 19:54, huizhe wang wrote:
A quick fix to remove path for the temporary output file so that it's
created in the working directory instead:
http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/
Just reading this now and wondering about
Changeset: a8a044db575c
Author:joehw
Date: 2013-11-05 11:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8a044db575c
8027860: [TEST_BUG] File not closed in
javax/xml/jaxp/parsers/8022548/XOMParserTest.java
Reviewed-by: alanb
!
Hi,
The issue is that the limits applied to each processing process rather
than each file processing. This applies to not only StAX as reported,
but also other parsers and validators. The fix is to add reset to
XMLSecurityManager and call it upon each file processing. XSLT Transform
is
On 11/13/2013 1:33 PM, Alan Bateman wrote:
On 13/11/2013 20:02, huizhe wang wrote:
Hi,
The issue is that the limits applied to each processing process
rather than each file processing. This applies to not only StAX as
reported, but also other parsers and validators. The fix is to add
reset
Thanks for working on the issue. The fix looks good.
Regards,
Joe
On 11/20/2013 7:58 PM, Patrick Zhang wrote:
Hi Everyone,
I am working on https://bugs.openjdk.java.net/browse/JDK-8027973. The
problem is caused by wrong URL format on windows. file://c:\xxx is one
invalid schema.
comments to XSLTExFuncTest.java.
I have updated the webrev for review.
http://cr.openjdk.java.net/~pzhang/8027973/webrev/
Regards
Patrick
On 11/21/13 5:33 PM, Alan Bateman wrote:
On 21/11/2013 05:20, huizhe wang wrote:
Thanks for working on the issue. The fix looks good.
Looks good to me too
On 11/23/2013 6:38 AM, Alan Bateman wrote:
On 21/11/2013 10:48, Patrick Zhang wrote:
Hi Alan,
I have renamed jdk8004476 to 8004476. And as Daniel's suggestion,
add some comments to XSLTExFuncTest.java.
I have updated the webrev for review.
http://cr.openjdk.java.net/~pzhang/8027973/webrev/
Hi,
This is a patch to fix an error in StAX factories' newFactory(String
factoryId, ClassLoader classLoader). In the 3 step of the documentation,
it should have stated that the specified ClassLoader is used.
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/webrev/
Thanks,
Joe
Changeset: 0bf3a58a1783
Author:joehw
Date: 2013-11-25 16:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bf3a58a1783
8027973: javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win)
Reviewed-by: alanb, dfuchs, joehw
Contributed-by: patrick.zh...@oracle.com
+
Hi all,
Here's revised webrev, as Alan suggested, including the implementation.
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/
Thanks,
Joe
On 11/26/2013 8:09 AM, Alan Bateman wrote:
On 25/11/2013 21:51, huizhe wang wrote:
Hi,
This is a patch to fix an error in StAX
On 11/26/2013 1:37 PM, Alan Bateman wrote:
On 26/11/2013 18:38, huizhe wang wrote:
Hi all,
Here's revised webrev, as Alan suggested, including the implementation.
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/
So is this handling the null case correctly? It is spec'ed to use
function.
Yes. I forgot that part. load(service, loader) treats null as the system
class loader was one of the topics in the discussion of the spec.
Joe
Roger
On 11/26/2013 4:37 PM, Alan Bateman wrote:
On 26/11/2013 18:38, huizhe wang wrote:
Hi all,
Here's revised webrev, as Alan suggested
On 11/27/2013 2:03 AM, Alan Bateman wrote:
On 26/11/2013 22:13, huizhe wang wrote:
Ah, I missed that. I took it for granted that since
ServiceLoader.load(service) uses TCCL, load(service, null) would use
TCCL. I've updated the webrev now:
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR
Changeset: aed9ca4d33ec
Author:joehw
Date: 2013-12-04 00:17 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/aed9ca4d33ec
8027973: Error in the documentation for newFactory method of the
javax.xml.stream factories
Reviewed-by: alanb, dfuchs, lancea, rriggs
!
Hi,
This is a quick documentation change to fix an error in
javax.xml.stream.XMLOutputFactory:
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
Thanks,
Joe
On 12/11/2013 12:21 PM, Alan Bateman wrote:
On 11/12/2013 19:52, huizhe wang wrote:
Hi,
This is a quick documentation change to fix an error in
javax.xml.stream.XMLOutputFactory:
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
Thanks,
Joe
It looks okay although I think
Changeset: 3e5bf0372a93
Author:joehw
Date: 2013-12-12 11:36 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3e5bf0372a93
8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect
specification
Reviewed-by: alanb, dfuchs, lancea
!
Hi,
This is a quick fix for a whitespace buffer that was not adjusted
properly in one of the two cases. The buffer, whiteSpaceLookup, is
filled in two cases and adjusted properly the 2nd time. The code is
moved into a method storeWhiteSpace so that it's shared for the 1st case
as well.
around if clause, else and after commas.)
-Ulf
On 16.12.2013 20:31, huizhe wang wrote:
Hi,
This is a quick fix for a whitespace buffer that was not adjusted
properly in one of the two cases. The buffer, whiteSpaceLookup, is
filled in two cases and adjusted properly the 2nd time. The code
http://cr.openjdk.java.net/~joehw/jdk8/8029955/webrev/
Joe
Fine.
But: ERROR: Line 1216 should be removed !!!
Done, thanks.
Why didn't you like this very short version? :
JAXP currently maintains a code level 1.5 (Apache Xerces at 1.4). While
we're getting close to the end of JAXP
Changeset: 73473e9dfc46
Author:joehw
Date: 2013-12-20 09:56 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73473e9dfc46
8029955: AIOB in XMLEntityScanner.scanLiteral upon parsing literals with 100
LF chars
Reviewed-by: dfuchs, lancea, ulfzibis
+
Update copyright date on JAXP files in jdk8 repository edited in 2013.
This patch will be applied to JDK8 and 9 repositories.
https://bugs.openjdk.java.net/browse/JDK-8029236
http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/
Thanks,
Joe
tel:+1.781.442.2037
Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad
On Dec 23, 2013, at 12:56 PM, huizhe wang huizhe.w...@oracle.com
Changeset: 9a3986b21be4
Author:joehw
Date: 2013-12-23 11:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9a3986b21be4
8029236: Update copyright year to match last edit in jdk8 jaxp repository for
2013
Reviewed-by: lancea, mchung
!
Hi,
This is an issue with the XML 1.1 scanner. Any reference to the data
buffer needs to be removed, that is, the content copied, when the buffer
is reloaded with new data. The fix is to duplicate the solution from the
XML 1.0 scanner.
webrev:
, MA 01803 x-apple-data-detectors://34/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPad
On Jan 3, 2014, at 1:07 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Hi,
This is an issue with the XML 1.1 scanner. Any reference to the data
Hi,
Please review a javadoc change to javax.xml.stream factories. This
change makes it clear that the two args ServiceLoader#load method is
used when the specified classLoader is not null.
http://cr.openjdk.java.net/~joehw/jdk9/8032392/webrev/
Thanks,
Joe
Thanks Lance, Daniel.
On 1/24/2014 12:53 PM, Lance Andersen - Oracle wrote:
+1
On Jan 24, 2014, at 3:31 PM, huizhe wang wrote:
Hi,
Please review a javadoc change to javax.xml.stream factories. This change makes
it clear that the two args ServiceLoader#load method is used when the specified
Hi,
We'd like to propose a JEP to update the Xerces implementation in the
JDK and bring it to up to date to the current Xerces release. Please
review the draft.
Thanks,
Joe
JEP:
Title: Updating JAXP to Xerces 2.11.0
Author: Joe Wang
Organization: Oracle
Created: 2014/01/24
Type: Feature
.
Thanks,
Joe
On 2/3/2014 2:08 PM, Sean Mullan wrote:
On 02/03/2014 02:19 PM, huizhe wang wrote:
The JDK contains an older Xerces implementation, version 2.7.1.
Although there were
updates in JDK 7 to bring in some changes, we did not bring it
completely up to date
to any later release. The goal
Hi,
This is an update from Xerces for two datatype classes
XMLGregorianCalendarImpl and DurationImpl. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8033980
webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/
Tests included for: 1243, 1416, 1097 (Note that
Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
On Feb 10, 2014, at 6:53 PM, huizhe wang huizhe.w...@oracle.com wrote:
Hi,
This is an update from Xerces for two datatype classes
XMLGregorianCalendarImpl and DurationImpl. For details, please
Hi Volker,
I agree with the approach below and jdk9/dev is the better forest.
For the test itself, I would suggest reducing the following loop to 1 or
2 cases:
for (int i = 0; i testString.length(); i++) {
test(createDocument(testString.toString(), i), + i);
}
and adds the benefit of having the same source as that of Xerces.
Thanks,
Joe
On 2/11/2014 10:56 AM, huizhe wang wrote:
On 2/11/2014 9:05 AM, Daniel Fuchs wrote:
On 2/11/14 5:55 PM, Lance @ Oracle wrote:
Hi joe
It looks like you changed the serialversionuid in Durationimpl, did
it get
, i.e. before/at/after
special characters like , or / as well as inside tags and content.
We can easily adapt the loop, if runtime is a concern here.
Regards,
Steffen
-Original Message-
From: huizhe wang [mailto:huizhe.w...@oracle.com]
Sent: Dienstag, 11. Februar 2014 22:57
To: Volker
the revision from
the patch as a result.
Please see the new webrev here:
http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/
Thanks,
Joe
On 2/12/2014 11:45 AM, Alan Bateman wrote:
On 12/02/2014 04:26, huizhe wang wrote:
Hi Lance, Daniel,
I suggest we take this incompatibility and document
wrote:
On 13/02/2014 08:18, huizhe wang wrote:
Hi Alan, Lance, and Daniel,
The Xerces serialization revision meant to create a serialization
form that would help maintain future serialization compatibility. But
in reality it itself is causing significant incompatibility as Alan
pointed out
to initialize the orig_* fields as done in the constructors.
http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/
Thanks,
Joe
On 2/17/2014 8:23 AM, Daniel Fuchs wrote:
Hi Joe,
Sorry for the late reply...
On 2/14/14 6:35 PM, huizhe wang wrote:
Hi All,
I added a SerializationTest. The test
On 2/18/2014 3:39 AM, Daniel Fuchs wrote:
On 2/17/14 11:17 PM, huizhe wang wrote:
Thanks Daniel.
I updated the test to call class.getResourceAsStream (see fromFile
method) instead at the runtime. The filePath now is only used for the
helper method to generate test file. Also added readObject
On Wed, Feb 12, 2014 at 7:25 PM, huizhe wang huizhe.w...@oracle.com wrote:
Ok, understand.
Thanks,
Joe
On 2/11/2014 11:40 PM, Schreiber, Steffen wrote:
Hi Joe,
Yes, that's certainly true, if the test is only to show the issue.
We intended the test to work as a regression test as well and wanted
, huizhe wang wrote:
On 2/18/2014 3:39 AM, Daniel Fuchs wrote:
On 2/17/14 11:17 PM, huizhe wang wrote:
Thanks Daniel.
I updated the test to call class.getResourceAsStream (see fromFile
method) instead at the runtime. The filePath now is only used for the
helper method to generate test file. Also
Hi Aleksej,
The change looks good. It's good to consolidate test cases into a single
test for each encoding.
Thanks,
Joe
On 2/20/2014 6:54 AM, Aleksej Efimov wrote:
Hi,
There is a problem in XSLT string-length function:
When string passed to this function contains complementary chars the
Hi,
This is a fix to the license header for class
jdk/test/javax/xml/jaxp/transform/8004476/TestBase.java.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8036004
Webrev:
http://cr.openjdk.java.net/~joehw/jdk9/8036004/webrev/
Thanks,
Joe
On 2/28/2014 12:01 AM, Alan Bateman wrote:
On 28/02/2014 07:51, huizhe wang wrote:
Hi,
This is a fix to the license header for class
jdk/test/javax/xml/jaxp/transform/8004476/TestBase.java.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8036004
Webrev:
http
Looks good. I'll sponsor the change.
Thanks,
Joe
On 2/28/2014 2:16 PM, Lance Andersen - Oracle wrote:
Looks fine.
On Feb 28, 2014, at 5:11 PM, David Li wrote:
Hi,
This is an update from Xerces for a fixed encoding map entry in file
EncodingMap.java. For details, please refer to:
On 3/5/2014 12:46 PM, Lance Andersen - Oracle wrote:
On Mar 5, 2014, at 3:37 PM, Xueming Shen wrote:
nitpicking,
(1) shouldn't the variable at #468 to be updated to lch instead of uch as
well?
I would agree given you are now calling Character.toLowerCase
Also, at line 463 and 464, it
On 3/5/2014 1:38 PM, Alan Bateman wrote:
On 05/03/2014 20:18, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs:
On 3/6/2014 12:31 AM, Alan Bateman wrote:
On 05/03/2014 22:17, huizhe wang wrote:
On 3/5/2014 1:38 PM, Alan Bateman wrote:
On 05/03/2014 20:18, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https
Thanks David for the update!
Joe
On 3/13/2014 4:07 PM, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs:
On 3/14/2014 7:38 AM, Alan Bateman wrote:
On 13/03/2014 23:07, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs:
I may be wrong, but the test passes without the patch. It looks like we
may need to fix the bug David found:
https://bugs.openjdk.java.net/browse/JDK-8037324
-Joe
On 3/14/2014 10:01 AM, huizhe wang wrote:
On 3/14/2014 7:38 AM, Alan Bateman wrote:
On 13/03/2014 23:07, David Li wrote:
Hi
On 3/20/2014 8:40 AM, Lance Andersen - Oracle wrote:
I think this OK.
The comments with the o--o did not do much for me though and found them a bit
confusing but perhaps I need more coffee this morning ?
Black or white? :-)
It illustrates an intersection. For example, the result of the
Hi Nico,
The JDK is a few patches short of Xalan 2.7.1. At least one of the
patches caused performance regression, which was the main reason they
were not brought in. We plan to fix the issue and bring JDK to Xalan
version 2.7.1.
Could you file at https://bugs.openjdk.java.net/browse/JDK?
Hi Alan,
The webrev looks good to me.
On 5/12/2014 11:02 AM, Alan Bateman wrote:
In JDK 8 we brought in a tiny XML parser to support the Properties
loadFromXML/storeToXML methods. We needed this for the Compact
Profiles work, specifically builds of compact1 as they do not have
JAXP/XML
On 5/13/2014 1:50 AM, Alan Bateman wrote:
On 12/05/2014 20:22, huizhe wang wrote:
Would you think the wordings in the javadoc of Properties could be
stronger in terms of encoding, e.g. instead of:
The |loadFromXML(InputStream)|
http://docs.oracle.com/javase/8/docs/api/java/util
Refer to 8042889, while verifying/testing 8042889, we noticed that the
tiny XML parser failed on UTF-16BE or LE. The cause of the failure was
that the parser was actually implemented to abide by the XML
specification that required entities encoded in UTF-16 to begin with
BOM. The test we used
Removing unused files in jaxp repository. Most of them are
META-INF/services files used by Apache build process. The COPYING files
at the bottom came with SAX, but they are included in the
THIRD_PARTY_README file already. Please review.
http://cr.openjdk.java.net/~joehw/jdk9/8043666/webrev/
:
On 05/27/2014 10:46 AM, huizhe wang wrote:
Hi,
Are you okay with the updated patch?
Thanks,
Joe
looks fine for me.
Btw, if I took a quick look at the UTF8 reader, my observation
suggests read byte by byte
from the underlying stream probably is the bottleneck of the overall
parsing
Hi David,
Good work!
This is a major patch in Xalan, one last in Xalan 2.7.1. Previously, it
caused many failures in JCK and SQE regression tests. I see that you've
resolved those failures with the fix stated below, and getting all tests
to pass.
Some minor cleanup may be desirable, such
setCdataSectionElements
-Joe
On 6/4/2014 2:04 PM, David Li wrote:
Hi Joe,
I have applied these changes and uploaded for review.
http://cr.openjdk.java.net/~dli/8041523/webrev/. Let me know if you
see anything else.
Thanks,
David
On 6/4/2014 12:27 PM, huizhe wang wrote:
Hi David,
Good work
Ok, Looks good.
Thanks,
Joe
On 6/4/2014 2:44 PM, David Li wrote:
I just checked and it is removed in my browser. I think you may need
to clear your browser cache (or use a different browser). That's what
I had to do before the changes would show up.
-David
On 6/4/2014 2:26 PM, huizhe wang
Fix some typos in the JAXP documentation. Please review.
http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/
Thanks,
Joe
Thanks Daniel, Chris!
-Joe
On 6/11/2014 9:11 AM, Daniel Fuchs wrote:
Hi Joe,
Looks good!
-- daniel
On 6/11/14 5:54 PM, huizhe wang wrote:
Fix some typos in the JAXP documentation. Please review.
http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/
Thanks,
Joe
have more than one paragraph in the doc comment, separate the
paragraphs with a |p|paragraph tag, as shown.
[1]
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
-Joe
otherwise it is OK
Best
Lance
On Jun 11, 2014, at 11:54 AM, huizhe wang huizhe.w...@oracle.com
,
getting rid of these type of pblah/p blocks was needed and just
use p
Best
Lance
On Jun 11, 2014, at 1:20 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
On 6/11/2014 9:48 AM, Lance Andersen wrote:
Hi Joe,
please change
dont
to
don't
Oops, I committed
can be put to good use in our writings :-)
-Joe
On 6/11/14 10:49 AM, huizhe wang wrote:
And, here is a good discussion on closing tags:
http://webdesign.about.com/od/htmltags/qt/optional-html-end-tags-when-to-include-them.htm
-Joe
On 6/11/2014 10:24 AM, Lance Andersen wrote:
Hi Joe
Hi,
This is a long time compatibility issue: Duration.compare returns equal
for INDETERMINATE relations defined in XML Schema standard
(http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
following table:
Relation
P*1Y*P*364D* P*365D* P*366D*
tag serves
only to separate paragraphs.
As for clutter, you probably hate xml then :-) I consider html tags are
generally short and tidy. But again, it's preference, if no /p is the
norm, I'll do the same.
-Joe
On 6/17/2014 3:38 PM, Stuart Marks wrote:
On 6/16/14 9:33 PM, huizhe wang wrote
Hi Henry,
Is it possible to add to the @since tool/script to remove repository
revision notes? They appear in the API document as if they reflect
meaningful version. An example in
/2014 03:36 PM, huizhe wang wrote:
Hi Henry,
Is it possible to add to the @since tool/script to remove repository
revision notes? They appear in the API document as if they reflect
meaningful version. An example in
http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers
:-)
The other changes are purely clean-up and in one case, JavaDoc.
http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
Best regards,
Joe
into a static final constant in the class.
best regards,
-- daniel
On 6/17/14 9:19 PM, huizhe wang wrote:
Hi,
This is a long time compatibility issue
!
This is much cleaner indeed :-)
-- daniel
On 6/21/14 4:36 AM, huizhe wang wrote:
Thanks Daniel, Lance.
On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
Hi Joe,
Thanks for the detailed explanation.
It really helps reviewing the fix!
Glad to know it helps. I thought this part of spec could be
unfamiliar
Hi,
We're planning on a jaxp project to address usability issues in the JAXP
API. One of the complaints about the JAXP API is the number of lines of
code that are needed to implement a simple task. Tasks that should take
one or two lines often take ten or twelve lines instead. Consider the
On 6/24/2014 12:19 AM, Alan Bateman wrote:
On 24/06/2014 01:14, huizhe wang wrote:
:
One thing that concerns me a bit is that none of the .java files
that I looked at have any comments to say what the test does. Is
there anything that could be brought over from the original issue in
JIRA
, Henry Jen wrote:
Looks like it's pretty easy to do a find and replace in files in jaxp
folder. If this is desired, we can do it in a separate webrev to be
clear on changeset history?
Cheers,
Henry
On 06/20/2014 03:36 PM, huizhe wang wrote:
Hi Henry,
Is it possible to add to the @since tool
Thanks Michael! And, welcome to core-libs-dev! :-)
On 6/26/2014 4:02 AM, Michael Kay wrote:
Here are some quick thoughts about the state of XML support in the JDK:
1. XML Parser. The version of Xerces in the JDK has long been buggy, and no-one
has been fixing the bugs. It needs to be replaced
, at 4:07 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
That makes sense. I changed @since back to 1.4 and added L2 in the
description:
http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/
http://cr.openjdk.java.net/%7Ejoehw/jdk9/8037948/webrev/
Thanks,
Joe
Hi,
Three packages are missing from the DOM API documentation in JAXP:
org.w3c.dom.views
org.w3c.dom.ranges
org.w3c.dom.traversal
We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since
we were too close to the deadline for JAXP 1.6 MR, we left the other
Thanks Mandy, Lance. The changeset is pushed.
-Joe
On 6/30/2014 5:02 PM, Mandy Chung wrote:
On 6/30/14 2:32 PM, huizhe wang wrote:
Hi,
Three packages are missing from the DOM API documentation in JAXP:
org.w3c.dom.views
org.w3c.dom.ranges
org.w3c.dom.traversal
We
These packages were defined in JDK 1.5 / JAXP 1.3 (JSR 206). In that
sense, they were in JDK since 1.5.
For reasons I don't know, they were excluded from the Java API
Documentation. From the tag conventions
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#@since
Hi Miran,
In class src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java:
+// hack to force initialization so catalog manager system
properties take effect
+staticManager.getVerbosity();
Is that necessary? I thought the next call to getCatalog would
On 7/9/2014 4:13 AM, Miroslav Kos wrote:
Hi Joe,
thanks for comments - see inline:
On 08/07/14 01:02, huizhe wang wrote:
Hi Miran,
In class
src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java:
+// hack to force initialization so catalog manager
system properties
Hi,
JAXP SecurityManager was re-designed to XMLSecurityManager to manage
jaxp related limits or restrictions. Previously, the existence of a
SecurityManager was equivalent to setting FEATURE_SECURE_PROCESSING to
true. After the change, secure processing became a property of
Thanks Lance.
Joe
On 7/16/2014 4:21 PM, Lance Andersen wrote:
Seems fine Joe…
On Jul 16, 2014, at 11:47 AM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Hi,
JAXP SecurityManager was re-designed to XMLSecurityManager to manage
jaxp related limits
Hi Aleksej,
The change looks good.
Thanks,
Joe
On 7/22/2014 6:10 AM, Aleksej Efimov wrote:
Hello,
Please review the fix [1] for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8029837
The problem was discovered during usage of not compatible old JAXB/XJC
classes on the stack
Hi all,
This is part of Xerces update: move to a common serialization codebase
with Xalan. As noted in one of the mailing list discussions:
Xalan's serializer has the same baseline capability as Xerces' Java serializer,
effort was devoted to improve its performance
and fix bugs and it is
Hi Eric,
This is a good start! The code looks much more cleaner than the
previous tests, great work!
1. Base class
I see that you picked a small set of tests from the Product group
(a small surprise :-) since I thought you'd had the Auction-portal
group). You probably already
fine otherwise.
Best,
Lance
On Jul 24, 2014, at 8:39 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Hi all,
This is part of Xerces update: move to a common serialization
codebase with Xalan. As noted in one of the mailing list discussions:
Xalan's serializer has
the As of JDK
1.X clause)
either way I am OK.
Best
Lance
On Jul 29, 2014, at 5:42 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Hi Lance,
You're right. The original content for deprecation was a copy of that
of Xerces, which is incorrect for the JDK. What
:+1.781.442.2037
Oracle Java Engineering
1 Network Drive x-apple-data-detectors://28/0
Burlington, MA 01803 x-apple-data-detectors://28/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPhone
On Jul 29, 2014, at 9:23 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w
Please review an one line fix:
http://cr.openjdk.java.net/~joehw/jdk9/8053965/webrev/
Thanks,
Joe
Thanks Lance, Alan!
Joe
On 7/30/2014 10:04 AM, Alan Bateman wrote:
On 30/07/2014 17:58, huizhe wang wrote:
Please review an one line fix:
http://cr.openjdk.java.net/~joehw/jdk9/8053965/webrev/
Looks good, easy to see how this was missed in the review.
-Alan.
Hi Aleksej,
The change looks good, as we discussed previously.
Thanks,
Joe
On 7/30/2014 9:32 AM, Aleksej Efimov wrote:
Hi,
Please, review the fix [1] for the Node.getTextContent() bug:
https://bugs.openjdk.java.net/browse/JDK-8032908
Problem description:
When Node#getTextContent is called
Hi Tristan,
Nice work! As with those converted by Eric (8051561), the new tests
looked much better and cleaner than the original ones.
I see that you're using jaxp.library instead of a base class as in
Eric's previous webrev. Is this the final decision on the whole test
structure? It
with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Hi,
Please review update to XMLSchemaFactory along with changes to relevant
classes. All new tests passed, as well as existing jaxp tests and JPRT.
Note that this updates XMLSchemaFactory, related classes such as
XMLShemaValidator are only updated to the related revisions. Full update
of
into that hosted in
Aurora. Please consider taking the patches from them if you haven't
already done so.
Thanks,
Joe
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
By the way, the plan has been that all of the JAXP
-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
Behalf Of huizhe wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin
tests: org.xml.sax to jtreg (testNG) tests
On 8/27/2014 4:03 PM, Tristan
chain.
Best Regards
Frank
-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of huizhe wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin
Hi,
This is an update to Xerces' Catalog Resolver implementation. The
changes were mostly performance related, for example the changes to the
normalizeURI method in Catalog.java to avoid creating new Strings if the
input is already in normalized form.
Bug:
1 - 100 of 553 matches
Mail list logo
