:09 PM, Lance Andersen wrote:
Hi Joe,
As we discussed off-line, these changes look OK. Please double check
that the copyright is updated in the relevant files.
Best
Lance
On May 20, 2019, at 7:06 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review an enhancement to
Please review an enhancement to the DOM and SAX factories. By default,
DOM/SAX factories created using the existing newInstance methods do not
support XML Namespace. Parsers instantiated with such factories would
therefore ignore namespaces. Users not realizing or unaware of the
legacy setting
Thanks Lance! I re-ran all of tests (inc JCK), they all still pass.
Pushed the patch now.
Best,
Joe
On 5/8/19, 1:30 PM, Lance Andersen wrote:
Hi Joe,
Sorry for the delay. The patch looks good.
Best
Lance
On Apr 29, 2019, at 6:03 PM, Joe Wang <mailto:huizhe.w...@oracle.com>&
Thanks Lance!
--Joe
On 5/1/19, 2:23 PM, Lance Andersen wrote:
Hi Joe,
the change looks OK as does the test.
On May 1, 2019, at 12:46 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a fix for a regression introduced during JDK 9
development. The issue was tha
Please review a fix for a regression introduced during JDK 9
development. The issue was that a patch ported to the JDK added a
counter to count the number of values found in the XML document, and
then compared with the constraint's field count. The problem was that
the counter would get
Please review an update on the Validation implementation. All XML tests
and JCK passed.
JBS: https://bugs.openjdk.java.net/browse/JDK-8222991
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8222991/webrev/
Thanks,
Joe
Hi Lance,
No problem. Thanks for reviewing the patch in between your busy schedules!
Best,
Joe
On 4/25/19, 11:51 AM, Lance Andersen wrote:
Hi Joe,
Sorry for the delay but took a while to go through :-)
I think your changes look good overall
On Apr 19, 2019, at 4:19 PM, Joe Wang
Please review an update to xerces/dom. Details are as described in the
JBS. XML related tests and JCK passed.
JBS: https://bugs.openjdk.java.net/browse/JDK-8222743
webrev: http://cr.openjdk.java.net/~joehw/jdk13/8222743/webrev/
Thanks,
Joe
to update the webrev
HTH
Best
Lance
On Apr 15, 2019, at 3:46 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review an update from Xerces in the configuration area. The
patch contains changes not easily measurable with test (e.g. a few
bytes for a parse, or small leaks f
Please review an update from Xerces in the configuration area. The patch
contains changes not easily measurable with test (e.g. a few bytes for a
parse, or small leaks for a file as large as a GB, or none at all). But
the change does improve in that a method ( readAndBuffer) that
explicitly
Please review a patch for the wrong headings. This patch passed build
with the new doclint enabled and doccheck (thanks Jon!)
JBS: https://bugs.openjdk.java.net/browse/JDK-8220254
webrev: http://cr.openjdk.java.net/~joehw/jdk13/8220254/webrev/
Thanks,
Joe
Thanks Lance, Brian!
-Joe
On 3/27/19, 1:37 PM, Lance Andersen wrote:
+1
On Mar 27, 2019, at 3:51 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a trivial fix for the missing commas in three class files.
hg diff
diff --git
a/src/java.xml/share/classes/com/sun/o
Please review a trivial fix for the missing commas in three class files.
hg diff
diff --git
a/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java
On 3/11/19, 11:54 AM, Lance Andersen wrote:
Hi Joe,
On Mar 11, 2019, at 2:41 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Thanks Lance!
The assertEquals message adds the name (prNames[i]) of the property
(e.g. media-type) so that it shows "java.lang.AssertionErro
p the test
assertEquals message it is just the name
Assert.assertEquals(value, prValues[i], prNames[i]);
HTH
Best
Lance
On Mar 11, 2019, at 2:22 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a fix for a JCK failure. All XML-related JCK and SQE
tests passed after the
Please review a fix for a JCK failure. All XML-related JCK and SQE tests
passed after the patch.
JBS: https://bugs.openjdk.java.net/browse/JDK-8219705
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219705/webrev/
Thanks,
Joe
, please put the ‘*/“ on its own line
Done.
Thanks,
Joe
On Feb 13, 2019, at 1:15 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a cleanup patch for the OutputPropertiesFactory.
The original intention was to remove the (awkward) JDK 1.2-related
code, line 235-258 i
Please review a cleanup patch for the OutputPropertiesFactory.
The original intention was to remove the (awkward) JDK 1.2-related code,
line 235-258 in the old file. I then went a bit further to remove
another nuisance that annoyed users with an error "Could not load the
property file
Thanks, Lance and Roger! The changeset is pushed now.
Best,
Joe
On 2/5/19, 11:52 AM, Lance Andersen wrote:
Hi Joe,
The change seems reasonable...
On Feb 5, 2019, at 1:37 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a quick fix for preserving the init
Please review a quick fix for preserving the initial state of the
Transformer. The faulty impl passes a reference of the initial property
setting to the working copy during reset, thus causes it to be altered
by an user setting. Further reset would then no longer be able to return
to the
Thanks, Roger and Lance! The changeset is pushed now.
Best,
Joe
On 2/4/19, 11:00 AM, Lance Andersen wrote:
Hi Joe
+1
On Feb 4, 2019, at 12:34 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Resend. Please review at your convenience.
Thanks,
Joe
Origina
Resend. Please review at your convenience.
Thanks,
Joe
Original Message
Subject: Re: RFR(JDK 13/java.xml) 8206132: DOM parser does not honor
DocumentBuilderFactory.setExpandEntityReferences(false)
Date: Fri, 25 Jan 2019 10:20:28 -0800
From: Joe Wang
Organization
Thanks Brian, Lance! Changeset was pushed.
-Joe
On 1/31/19, 12:02 PM, Brian Burkhalter wrote:
+1
Thanks,
Brian
On Jan 31, 2019, at 12:01 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Done.
Updated the webrev with the addition of FuncDoclocation:
http://cr.openjdk.java.n
().findURIFromDoc(owner);
Done.
Updated the webrev with the addition of FuncDoclocation:
http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/
Thanks,
Joe
Thanks,
Brian
On Jan 31, 2019, at 11:18 AM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a cleanup of
Please review a cleanup of an unused class. All core and xml tests passed.
JBS: https://bugs.openjdk.java.net/browse/JDK-8186321
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8186321/webrev/
Thanks,
Joe
Thanks Lance!
-Joe
On 1/25/19, 12:09 PM, Lance Andersen wrote:
all good still
On Jan 25, 2019, at 2:34 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi Daniel,
True, Objects.equals is better. While the default setting generally
won't be null, it's always good to cover all
no idea what would be the
right thing to do :-)
best regards,
-- daniel
On 25/01/2019 17:47, Joe Wang wrote:
Please review a fix for XMLStreamWriter.setDefaultNamespace that
throws NullPointerException when the value is null.
JBS: https://bugs.openjdk.java.net/browse/JDK-8216408
webrevs: http
://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/
Thanks,
Joe
On 1/18/19, 11:19 AM, Joe Wang wrote:
Please hold on reviewing the webrevs as the tests passed while the new
tests were commented out as Lance pointed out.
Thanks,
Joe
On 1/18/19, 10:05 AM, Joe Wang wrote:
Please review a change to the DOM
Please review a fix for XMLStreamWriter.setDefaultNamespace that throws
NullPointerException when the value is null.
JBS: https://bugs.openjdk.java.net/browse/JDK-8216408
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8216408/webrev/
Thanks,
Joe
Please hold on reviewing the webrevs as the tests passed while the new
tests were commented out as Lance pointed out.
Thanks,
Joe
On 1/18/19, 10:05 AM, Joe Wang wrote:
Please review a change to the DOM parser so that it complies with the
specification with regard to the ExpandEntityReferences
Please review a change to the DOM parser so that it complies with the
specification with regard to the ExpandEntityReferences feature. This
change corrects the behavior so that the resulting DOM tree includes
EntityReference nodes but not the expanded Text nodes when the feature
is off. It
Thanks Lance! The change is in now.
-Joe
On 1/3/19, 3:48 PM, Lance Andersen wrote:
Hi Joe,
The changes and test seem fine!
Happy New Year
On Jan 3, 2019, at 6:25 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a fix to the impl for the Catalog. The
Hi,
Please review a fix to the impl for the Catalog. The reporter was right,
in the Group case, we failed to update the currently longest match when
a match is found.
JBS: https://bugs.openjdk.java.net/browse/JDK-8215330
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8215330/webrev/
Hi Frank,
The change looks good to me. Thanks for fixing the failure!
Best,
Joe
On 12/4/18, 6:19 PM, Frank Yuan wrote:
Hi all
Would you like to review this patch?
Bug: https://bugs.openjdk.java.net/browse/JDK-8213300
Webrev: http://cr.openjdk.java.net/~fyuan/8213300/webrev.00/
This
Thanks Naoto for the fast review!
Best regards,
Joe
On 12/4/18, 1:53 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Those changes in the resource bundles look fine to me.
Naoto
On 12/4/18 1:45 PM, Joe Wang wrote:
Hi Naoto and all,
Could you please take a look at the changes to the resource
n 11/16/18, 2:27 PM, Joe Wang wrote:
Hi Daniel,
On 11/16/18, 10:32 AM, Daniel Fuchs wrote:
Hi Joe,
1. It looks as if the parser will not complain if the root element
is seen twice - and it looks as if it is a supported feature
since the previous implementation also had a counter.
Sh
Thanks Lance. Changed the for loop to a while loop:
http://cr.openjdk.java.net/~joehw/jdk12/8213734/webrev_02/
previous:
http://cr.openjdk.java.net/~joehw/jdk12/8213734/webrev_01/
-Joe
On 11/29/18, 11:17 AM, Joe Wang wrote:
Hi,
Please review a fix for the issue as reported
Hi,
Please review a fix for the issue as reported that the SAXParser does
not close the underlying reader. This code always existed in Xerces, but
it was somehow removed as the comment for the closeReaders method
showed. The comment stated "readers are closed in the endEntity method",
that
Thanks Lance!
On 11/28/18, 9:41 AM, Lance Andersen wrote:
Hi Joe
Looks good,
Best
Lance
On Nov 27, 2018, at 2:58 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a fix for the adoptNode impl. Before a node from a
deferred DOM can be adopted, it needs to
Hi,
Please review a fix for the adoptNode impl. Before a node from a
deferred DOM can be adopted, it needs to be fully expanded.
JBS: https://bugs.openjdk.java.net/browse/JDK-8213117
webrev: http://cr.openjdk.java.net/~joehw/jdk12/8213117/webrev/
Thanks,
Joe
Thanks Lance. I added noreg-trivial. All existing tests (including the
XSLT ones) passed.
-Joe
On 11/26/18, 12:08 PM, Lance Andersen wrote:
Hi Joe,
Looks OK. Is there an existing test for this? if so you will want to
update your labels in the bug.
On Nov 26, 2018, at 2:59 PM, Joe Wang
Hi,
Please review a quick fix that compares the String with the QName's
string representation.
JBS: https://bugs.openjdk.java.net/browse/JDK-8177286
Diff:
---
a/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java
+++
Thanks Lance!
Joe
On 11/19/18, 2:06 PM, Lance Andersen wrote:
Seems OK joe
On Nov 19, 2018, at 4:04 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a test patch below. The main change is removing the
references to openjdk.java.net <http://openjdk.java
Hi,
Please review a test patch below. The main change is removing the
references to openjdk.java.net. Since the Catalog feature sits above the
default resolution of external resources, there is no need for the tests
to depend on a real/live domain to test the feature that
enables/disables
-- daniel
On 15/11/2018 20:26, Joe Wang wrote:
Hi Daniel,
I deleted the endDTD method. It could have been used to signal the
end of DTD parsing and therefore serve as a validation point.
However, the parser would have thrown Exceptions if a DTD parsing
wasn't completed properly, that seems to make
/2018 05:18, Joe Wang wrote:
Hi,
Please review a patch to bring the small footprint parser for
java.util.Properties compliant with the specification.
JBS: https://bugs.openjdk.java.net/browse/JDK-8213325
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/
Thanks,
Joe
DTDHandler::endDTD methos is called.
Is that an oversight or is there more magic?
best regards,
-- daniel
On 14/11/2018 05:18, Joe Wang wrote:
Hi,
Please review a patch to bring the small footprint parser for
java.util.Properties compliant with the specification.
JBS: https
Hi,
Please review a patch to bring the small footprint parser for
java.util.Properties compliant with the specification.
JBS: https://bugs.openjdk.java.net/browse/JDK-8213325
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/
Thanks,
Joe
Checked in. Thanks all for all of the great help!
Best regards,
Joe
On 11/7/18, 11:39 AM, Ivan Gerasimov wrote:
Thank you Joe!
I like the last variant.
With kind regards,
Ivan
On 11/7/18 9:59 AM, Joe Wang wrote:
Thanks Ivan!
I agree that the upfront edge case checks aren't really
not mistaken, the code would work equally well, if lines
1596-1615 were replaced with just subrange 1606-1614.
With kind regards,
Ivan
On 11/6/18 12:53 PM, Joe Wang wrote:
Thanks Andrew for pointing that out. It wasn't intentional, a result
of copy n paste after removing the support class. It's fixed now
for testing when it is the same file doesn't seem
necessary.
Regards, Roger
On 11/05/2018 11:27 PM, Stuart Marks wrote:
On 10/19/18 11:26 AM, Joe Wang wrote:
Current version:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/
Hi Joe,
Thanks for updating the tests per my comments
iterations.
All together, that reduced the tests from 65 to 46.
http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v07/
Thanks,
Joe
Regards, Roger
On 11/05/2018 11:27 PM, Stuart Marks wrote:
On 10/19/18 11:26 AM, Joe Wang wrote:
Current version:
http://cr.openjdk.java.net/~joehw/jdk12
Thanks Stuart! I'm glad it's finally close to the end :-)
On 11/5/18, 8:27 PM, Stuart Marks wrote:
On 10/19/18 11:26 AM, Joe Wang wrote:
Current version:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/
Hi Joe,
Thanks for updating the tests per my comments. Everything looks good
Thanks Lance, again :-)
On 11/5/18, 12:34 PM, Lance Andersen wrote:
+1
On Nov 5, 2018, at 3:24 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a fix for the broken links to IANA-CHARSETS. While we
are here, I also updated the link to XML 1.0 since "RE
Hi,
Please review a fix for the broken links to IANA-CHARSETS. While we are
here, I also updated the link to XML 1.0 since "REC-xml-20040204" was
outdated. Both the current and outdated XML 1.0 spec actually referenced
the correct iana.org page for the charsets.
---
Thanks Lance!
On 11/5/18, 11:13 AM, Lance Andersen wrote:
+1
On Nov 5, 2018, at 2:10 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a correction of the links:
1. the 1st link shall point to the standard "Namespaces in XML", not
the inner ancho
Hi,
Please review a correction of the links:
1. the 1st link shall point to the standard "Namespaces in XML", not the
inner anchor to the "Qualified Names" section.
2. the 2nd link shall point to the html file
"xml-names-19990114-errata.html", not "xml-names-19990114-errata".
---
etwork Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Sent from my iPhone
On Nov 2, 2018, at 3:13 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review:
JBS: https://bugs.openjdk.java.net/browse/JDK-8213321
Changes:
---
Hi,
Please review:
JBS: https://bugs.openjdk.java.net/browse/JDK-8213321
Changes:
---
a/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java
+++
b/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java
@@ -4,9 +4,7 @@
*
* This code
040226/
<https://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/>
Was that intentional?
On Oct 31, 2018, at 8:02 PM, Joe Wang wrote:
Hi,
Please review a fix for the broken links, replacing:
http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820
with:
https://www.w3.org/TR/DOM-L
Hi,
Please review a fix for the broken links, replacing:
http://www.w3.org/2002/08/WD-DOM-Level-3-XPath-20020820
with:
https://www.w3.org/TR/DOM-Level-3-XPath/
The former on which the jdk.xml.dom package was based is no longer
publicly available. The later is current. The only difference
Thanks Lance!
On 10/26/18, 12:27 PM, Lance Andersen wrote:
looks OK Joe
On Oct 26, 2018, at 3:24 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Looks like schematron.com <http://schematron.com> is gone. Tested
since the issue was reported 3 days ago, each time
Hi,
Looks like schematron.com is gone. Tested since the issue was reported 3
days ago, each time got a database connection error. Schematron became
an ISO standard later after the JAXP specification and this packageinfo
page was written, so replacing the link to schematron.com with a pointer
(at the end).
397: fillArray could probably make good use of System.arraycopy().
Sure.
Current version:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/
Previous:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/
Thanks,
Joe
Regards, Roger
On 10/17/2018 03:33 PM, Joe Wang
k.java.net/~joehw/jdk12/8202285/webrev_v05/
Thanks,
Joe
Thanks, Roger
On 10/16/2018 02:10 PM, Joe Wang wrote:
Hi Daniel,
@linkplain it is! Thanks! And yes, int totalRead was fixed in the
previous webrevs.
Current version:
specdiff:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v0
10/2018 20:16, Joe Wang wrote:
Here's an update based on all of the great reviews and comments
(thanks all!):
JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
CSR: https://bugs.openjdk.java.net/browse/JDK-8202302
Current version:
specdiff:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/s
previous:
specdiff:
http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html
webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/
Thanks,
Joe
Thanks
Max
On Oct 13, 2018, at 3:16 AM, Joe Wang wrote:
Hi all,
Here's an update based on all of the gre
On 10/14/18, 11:08 AM, Alan Bateman wrote:
On 12/10/2018 20:16, Joe Wang wrote:
Hi all,
Here's an update based on all of the great reviews and comments
(thanks all!):
JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
CSR: https://bugs.openjdk.java.net/browse/JDK-8202302
Current
Thanks Joe for the reminder, and thanks all for doing this! The change
looks good to me as well. I assume you updated copyright locally, not
reflected in the webrev. With regards to the class documentation, it's
confusing probably due to a class refactoring during the development.
That part of
Wang wrote:
On 9/20/18, 2:46 PM, Stuart Marks wrote:
On 9/19/18 11:48 AM, Joe Wang wrote:
After much discussion and 10 iterations of reviews, this proposal
has evolved from what was the original isSameContent method to a
mismatch method. API-wise, a compare method was also considered
On 9/20/18, 2:46 PM, Stuart Marks wrote:
On 9/19/18 11:48 AM, Joe Wang wrote:
After much discussion and 10 iterations of reviews, this proposal has
evolved from what was the original isSameContent method to a mismatch
method. API-wise, a compare method was also considered as it looked
On 9/20/18, 8:10 AM, Brian Burkhalter wrote:
On Sep 19, 2018, at 5:59 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
I'll do some performance testing for both cases, FileChannel/direct
buffer and possible checksum comparison, although, as you said, the
later might not work
for that. Alternatively you could add a whitebox
test to test FilesMismatch.mismatch(InputStream, InputStream)
directly.
best regards,
-- daniel
On 19/09/2018 19:48, Joe Wang wrote:
Hi,
After much discussion and 10 iterations of reviews, this proposal has
evolved from what was the original isSameContent
On 9/20/18, 12:12 AM, Alan Bateman wrote:
On 19/09/2018 22:02, Roger Riggs wrote:
This came up in off-line discussions, it seems unlikely that two
files will differ only in the last of 100Mb
and it will require a separate code path that will very infrequently
be exercised. So I'd still to
On 9/20/18, 12:07 AM, Alan Bateman wrote:
On 20/09/2018 01:34, Joe Wang wrote:
:
The purpose of toRealPath is so that we can do a quick Path
comparison by following symlinks if any, I'll add a test to compare a
file and its symbolic link.
You don't need it. If two non-equals paths locate
On 9/19/18, 1:52 PM, Brian Burkhalter wrote:
On Sep 19, 2018, at 1:44 PM, Brian Burkhalter
wrote:
On Sep 19, 2018, at 1:14 PM, Alan Bateman wrote:
Starting out using buffered I/O is probably okay but I assume we will want to
change this in the future to having it use memory mapped I/O
On 9/19/18, 2:02 PM, Roger Riggs wrote:
Hi Alan,
On 9/19/18 4:14 PM, Alan Bateman wrote:
On 19/09/2018 19:48, Joe Wang wrote:
Hi,
After much discussion and 10 iterations of reviews, this proposal
has evolved from what was the original isSameContent method to a
mismatch method. API-wise
Hi,
After much discussion and 10 iterations of reviews, this proposal has
evolved from what was the original isSameContent method to a mismatch
method. API-wise, a compare method was also considered as it looked like
just a short step forward from mismatch, however, it was eventually
dropped
Thanks Lance! It's done now.
Joe
On 9/18/18, 10:46 AM, Lance Andersen wrote:
+1
On Sep 18, 2018, at 1:00 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi Lance,
I accidentally missed checking in the test for JDK-8209615.
Here's the original webrev for JDK-8209
Hi Lance,
I accidentally missed checking in the test for JDK-8209615.
Here's the original webrev for JDK-8209615:
http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/
and here's the webrev for requesting checking in the test:
http://cr.openjdk.java.net/~joehw/jdk12/8210874/webrev/
I kept
Thanks Daniel! Will run tests again before checking in.
-Joe
On 9/17/18, 1:43 PM, Daniel Fuchs wrote:
Hi Joe,
Looks right to me now.
Cheers,
-- daniel
On 17/09/18 19:44, Joe Wang wrote:
Yikes, right, the process must avoid advancing the index if the pair
is written when the current char
still missing something?
best regards,
-- daniel
On 14/09/2018 18:08, Joe Wang wrote:
Hi Daniel,
The additional advance is made when the pair has already been
written, which is indicated by the return value of
writeUTF16Surrogate being >= 0*. Encodings.isHighUTF16Surrogate(ch)
therefore wo
best regards,
-- daniel
On 14/09/2018 04:13, Joe Wang wrote:
Thanks Daniel.
I changed the return of writeUTF16Surrogate so that it is clearer
within writeUTF16Surrogate when an additional index increment is
needed. Other corresponding changes are in ToHTMLStream and
ToTextStream where similar calls t
ten.
I am not sure what `(ils && i != 0)` means, though...
best regards
-- daniel
On Sep 12, 2018, at 2:11 PM, Joe Wang wrote:
Hi,
Please review a patch for a situation where a surrogate pair is at
the edge of a buffer. What the existing impl did was to report it as
an error. T
Hi,
Please review a patch for a situation where a surrogate pair is at the
edge of a buffer. What the existing impl did was to report it as an
error. This patch fixes it by caching the high surrogate and prints it
out along with the low surrogate. Similar issue exists also in the CDATA
Thanks Lance!
Joe
On 8/23/18, 12:34 PM, Lance Andersen wrote:
+1
On Aug 23, 2018, at 3:27 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a quick fix for a typo in javax.xml.validation.Validator:
diff --git
a/src/java.xml/share/classes/javax/xml/v
Hi,
Please review a quick fix for a typo in javax.xml.validation.Validator:
diff --git
a/src/java.xml/share/classes/javax/xml/validation/Validator.java
b/src/java.xml/share/classes/javax/xml/validation/Validator.java
--- a/src/java.xml/share/classes/javax/xml/validation/Validator.java
+++
Thanks Lance! Yes, the test for 8158619 passed, as did all other xml
tests.
Best,
Joe
On 8/21/18, 12:01 PM, Lance Andersen wrote:
Hi Joe,
The change and test look fine. I assume the test for 8158619 is still
happy :-)
Best
lance
On Aug 21, 2018, at 2:17 PM, Joe Wang <mailto:huizh
Hi,
Please review a patch for a regression that was introduced in JDK 9 b147
by the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK parser
returns all contiguous character data in a single chunk. After the patch
then, the parser would return partially if the data is not read
Thanks Sherman!
All tests in core were passed. The patch is now pushed.
-Joe
On 8/17/18, 2:49 PM, Xueming Shen wrote:
+1
On 08/17/2018 02:39 PM, Joe Wang wrote:
Hi,
Please review a fix for a condition where a code conversion was
skipped incorrectly resulting in a wrong byte array being
Hi,
Please review a fix for a condition where a code conversion was skipped
incorrectly resulting in a wrong byte array being written into the file.
JBS: https://bugs.openjdk.java.net/browse/JDK-8209576
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209576/webrev/
Thanks,
Joe
Thanks Lance, and Jon!
-Joe
On 7/11/18, 10:49 AM, Lance Andersen wrote:
Hi Joe,
The updates like fine
On Jul 10, 2018, at 11:10 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
On 7/10/18, 4:39 PM, Jonathan Gibbons wrote:
On 7/10/18 4:27 PM, Joe Wang wrote:
Hi,
Plea
On 7/10/18, 4:39 PM, Jonathan Gibbons wrote:
On 7/10/18 4:27 PM, Joe Wang wrote:
Hi,
Please review a javadoc fix for a couple of incorrect references to
the javax.xml.stream package. Attribute and Namespace are both in the
javax.xml.stream.events, and so is StartElement where
Hi,
Please review a javadoc fix for a couple of incorrect references to the
javax.xml.stream package. Attribute and Namespace are both in the
javax.xml.stream.events, and so is StartElement where they are referenced.
JBS: https://bugs.openjdk.java.net/browse/JDK-8194680
webrevs:
Hi,
Please review a quick fix for a missing throw in what supposed to be a
throw statement.
JBS: https://bugs.openjdk.java.net/browse/JDK-8206164
webrev: http://cr.openjdk.java.net/~joehw/jdk12/8206164/webrev/
Thanks,
Joe
On 7/3/18, 1:31 AM, Daniel Fuchs wrote:
On 02/07/2018 22:55, Joe Wang wrote:
Thanks Roger, Lance! Pushed.
Oh - well - I was wondering whether there should be a test for
StreamReaderDelegate as well - but maybe there's already one?
The APIs should have been consistent. Unfortunately
Thanks Roger, Lance! Pushed.
Best,
Joe
On 7/2/18, 12:21 PM, Roger Riggs wrote:
+1
On 7/2/2018 3:07 PM, Lance Andersen wrote:
+1
On Jul 2, 2018, at 1:44 PM, Joe Wang wrote:
Hi,
Please review a patch that clarifies that XMLStreamReader.next()
throws NoSuchElementException when hasNext
Hi,
Please review a patch that clarifies that XMLStreamReader.next() throws
NoSuchElementException when hasNext() is false by removing the confusing
note.
JBS: https://bugs.openjdk.java.net/browse/JDK-8204329
CSR: https://bugs.openjdk.java.net/browse/JDK-8206084
webrevs:
Thanks Lance! Pushed.
-Joe
On 6/28/18, 5:22 PM, Lance Andersen wrote:
Looks OK joe.
On Jun 28, 2018, at 5:06 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a quick fix for the first of JDK12/JAXP.
JBS: https://bugs.openjdk.java.net/browse/JDK-819083
Hi,
Please review a quick fix for the first of JDK12/JAXP.
JBS: https://bugs.openjdk.java.net/browse/JDK-8190835
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8190835/webrev/
Thanks,
Joe
501 - 600 of 897 matches
Mail list logo
