Thanks all! Glad to be able to get this done right before the deadline :-)
-Joe
On 6/27/18, 12:44 AM, Alan Bateman wrote:
On 26/06/2018 20:49, Joe Wang wrote:
:
Removed the null check. The internal impl and test guarantees it's
not null indeed:
http://cr.openjdk.java.net/~joehw/jdk11
On 6/26/18, 11:57 AM, Alan Bateman wrote:
On 26/06/2018 18:41, Joe Wang wrote:
:
Yes, combined with Sherman's suggestion eliminated the need for the
new parameter. Here's the updated webrev:
http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev03/
This looks good.
Just a minor nit
ted string
* @throws IllegalArgumentException for malformed or unmappable bytes
*/
String newStringNoRepl(byte[] bytes, Charset cs) throws
CharacterCodingException;
include an @throws for CharacterCodingException?
On Jun 26, 2018, at 1:41 PM, Joe Wang <mailto:huizhe.w.
On 6/26/18, 6:54 AM, Alan Bateman wrote:
On 26/06/2018 05:50, Joe Wang wrote:
Hi Alan, Sherman,
Here's a version where we, as Sherman suggested, throw an IAE with
CCE as the cause. This approach reduces code duplication in SC,
although it complicates the impl a little bit with the added
mpl cleaner at least.
-Sherman
On 6/25/18, 9:50 PM, Joe Wang wrote:
Hi Alan, Sherman,
Here's a version where we, as Sherman suggested, throw an IAE with
CCE as the cause. This approach reduces code duplication in SC,
although it complicates the impl a little bit with the added
parameter and th
Wang wrote:
Hi Alan,
The test testMalformedRead and testMalformedWrite now expect an
UnmappableCharacterException instead of IOE:
webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev01/
Thanks,
Joe
On 6/25/18, 9:48 AM, Joe Wang wrote:
On 6/24/18, 12:11 PM, Alan Bateman wrote
Hi Alan,
The test testMalformedRead and testMalformedWrite now expect an
UnmappableCharacterException instead of IOE:
webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8205058/webrev01/
Thanks,
Joe
On 6/25/18, 9:48 AM, Joe Wang wrote:
On 6/24/18, 12:11 PM, Alan Bateman wrote:
On 20/06
On 6/24/18, 12:11 PM, Alan Bateman wrote:
On 20/06/2018 04:32, Joe Wang wrote:
Thanks Alan. I created 8205058 to capture your suggestions. Please
see below for more details.
Changed the internal APIs to throw CCE instead. In the same way as
the previous changeset for 8201276
Thanks Alan. I created 8205058 to capture your suggestions. Please see
below for more details.
On 6/14/18, 4:30 AM, Alan Bateman wrote:
On 12/06/2018 17:52, Joe Wang wrote:
Hi all,
It's been a while since the 1st round of reviews. Thank you all for
the valuable comments and suggestions
Thanks Roger!
I pushed the changeset after s/unmappble/unmappable, it found three of
them :-)
Best,
Joe
On 6/12/18, 10:37 AM, Roger Riggs wrote:
Hi Joe,
Looks good to me.
Typo: StringCoding.java:1026 "unmappble" (no new webrev needed)
Regards, Roger
On 6/12/2018 12:52 PM
I'd prefer "writeString" as a familiar term that isn't stretched too
far by making the argument be a CharSequence.
its fine to call a CharSequence a string (with a lower case s).
$.02, Roger
On 4/27/18 6:33 PM, Joe Wang wrote:
On 4/27/2018 12:50 PM, fo...@univ-mlv.fr wrote:
-
Thanks Lance! Running one last test. Will check in once the tests pass.
Best,
Joe
On 5/18/2018 2:26 PM, Lance Andersen wrote:
Hi Joe,
The current webrev looks fine.
On May 16, 2018, at 7:40 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
P
Hi,
Please review a fix on synchronization. The real change is the
double-checked locking, all others are s/Token.categories/tmpMap/g.
All JAXP tests passed. Before the fix, the test attached to JBS failed
only once for me after 10,000 runs and then a few 1000 runs (impossible
to get one
Thanks Lance! I pushed after removing line 76.
Best,
Joe
On 5/15/18, 11:01 AM, Lance Andersen wrote:
Hi Joe,
Looks fine overall
Perhaps remove the commented out line of code on line 76
in StAXSourceTest.java before pushing
Best
Lance
On May 15, 2018, at 1:00 PM, Joe Wang <huizh
Hi,
Please review a fix that adds better tolerance for a XMLStreamReader
reporting no attribute type, in which case, the default CDATA type is used.
JBS: https://bugs.openjdk.java.net/browse/JDK-8202426
webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8202426/webrev/
Thanks,
Joe
u fine with that?
I’ll run it through the jtreg suite before pushing, of course.
Best regards
Christoph
*From:*Joe Wang [mailto:huizhe.w...@oracle.com]
*Sent:* Donnerstag, 10. Mai 2018 20:08
*To:* Langer, Christoph <christoph.lan...@sap.com>;
core-libs-dev@openjdk.java.net
*Subject:
, Langer, Christoph wrote:
One addition: I think it would be more appropriate to completely
remove the commented lines but I didn’t dare to do so yet. What do you
think?
*From:*Langer, Christoph
*Sent:* Donnerstag, 10. Mai 2018 17:51
*To:* core-libs-dev@openjdk.java.net; 'Joe Wang' <huizh
Thanks Lance!
On 5/3/2018 10:54 AM, Lance Andersen wrote:
Hi Joe,
The change looks good.
Best
Lance
On May 3, 2018, at 1:43 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a fix for a defect in XMLEventReader. The issue was
t
Hi,
Please review a fix for a defect in XMLEventReader. The issue was that
variable 'type' and 'data' were not set properly within the while statement.
JBS: https://bugs.openjdk.java.net/browse/JDK-8201138
webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8201138/webrev/
Thanks,
Joe
Thanks John for the background and detailed information.
-Joe
On 4/30/2018 6:18 PM, John Rose wrote:
On Apr 30, 2018, at 4:47 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Are there real-life use cases? It may be useful for example to check
if th
I see. Generalization vs solution in a specific scope, it's kind of a
balancing art indeed :-)
-Joe
On 4/30/2018 5:13 PM, Paul Sandoz wrote:
On Apr 30, 2018, at 4:47 PM, Joe Wang <huizhe.w...@oracle.com> wrote:
—
It’s tempting (well to me at least) to generalize to a mismatch method
quot; vs. "contents", I note that String has put a stake in the
ground for the singular form, with contentEquals.
https://docs.oracle.com/javase/9/docs/api/java/lang/String.html#contentEquals-java.lang.CharSequence-
-- Jon
On 4/30/18 4:02 PM, Joe Wang wrote:
Hi Jonathan,
has
On 4/30/2018 11:47 AM, Paul Sandoz wrote:
On Apr 27, 2018, at 4:30 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
On 27/04/2018 05:51, Joe Wang wrote:
Hi,
Considering extending isSameFile to add isSameContent to Files. Please review.
JBS: https://bugs.openjdk.java.net/brow
of other files, so hashing is better.
Rémi
- Mail original -
De: "Joe Wang" <huizhe.w...@oracle.com>
À: "nio-dev" <nio-...@openjdk.java.net>, "core-libs-dev"
<core-libs-dev@openjdk.java.net>
Envoyé: Vendredi 27 Avril 2018 06:51:08
On 4/27/2018 4:30 AM, Alan Bateman wrote:
On 27/04/2018 05:51, Joe Wang wrote:
Hi,
Considering extending isSameFile to add isSameContent to Files.
Please review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev
to discover that
the first byte differs.
Some lock-step reading of the two files would seem more appropriate.
best regards,
-- daniel
On 27/04/2018 05:51, Joe Wang wrote:
Hi,
Considering extending isSameFile to add isSameContent to
Files. P
ir content, especially if it's to discover that
the first byte differs.
Some lock-step reading of the two files would seem more appropriate.
best regards,
-- daniel
On 27/04/2018 05:51, Joe Wang wrote:
Hi,
Considering extending isSameFile to add isSameContent to Files.
Please review.
easily overflow heap. Besides the Javadoc is pretty
specific but fails to mention the size comparison.
Greetings
Bernd
Gruss
Bernd
--
http://bernd.eckenfels.net
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Joe Wang
<
and testMalformedRead, temp files are not
deleted, as Files.deleteIfExists(path); is skipped by the expected
IOException. File.deleteOnExit() may help.
Thank you
-Hamlin
On 27/04/2018 12:50 PM, Joe Wang wrote:
Hi,
We're looking into adding methods to Files to read a file into a
String/write
On 4/27/2018 12:50 PM, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Joe Wang" <huizhe.w...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>, "Alan Bateman" <alan.bate...@oracle.com>
Cc: "nio-dev" <nio-...@openjdk.java.n
- Mail original -
De: "Alan Bateman" <alan.bate...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>, "Joe Wang" <huizhe.w...@oracle.com>
Cc: "nio-dev" <nio-...@openjdk.java.net>, "core-libs-dev"
<core-libs-dev@openjd
On 4/27/2018 4:13 AM, Alan Bateman wrote:
On 27/04/2018 05:50, Joe Wang wrote:
Hi,
We're looking into adding methods to Files to read a file into a
String/write a String to a file. Below is the current proposal.
Please review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8201276
webrev
Hi,
Considering extending isSameFile to add isSameContent to Files. Please
review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/
specdiff:
Hi,
We're looking into adding methods to Files to read a file into a
String/write a String to a file. Below is the current proposal. Please
review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8201276
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/
specdiff:
Looks good to me. I verified the links using the Java SE 10 doc.
--Joe
On 4/3/2018 2:17 PM, Jonathan Gibbons wrote:
Please review a small update to fix some broken links in the java.base
API docs.
The change is necessary because when generating HTML 5 output, javadoc
no longer has to encode
-8199895
Best,
Joe
On 3/23/2018 10:49 AM, Roger Riggs wrote:
Hi Joe,
Looks fine.
(I would be in favor of a future solution that correctly
generated/fixed up the appropriate headers;
Manual editing and corrections are an unnecessary overhead.)
Thanks, Roger
On 3/21/2018 6:47 PM, Joe Wang wrote
/21/18 2:28 PM, Alan Bateman wrote:
On 21/03/2018 19:08, Joe Wang wrote:
:
*Item 3*: Heading leavels should only increase by one
This is due to the javadoc tool generates a header with an
addition of headings, in this particular case, . The fix for
this particular case is to replace the s
Hi,
Please an accessibility fix for several package-info files.
The report contained 4 items. Among them, 1 and 2 are issues in the
javadoc tool, and 3 could use an improvement in the tool or
documentation. For reference, please see the linked issues in JBS [1].
For the current issue,
Thanks!
On 3/20/2018 11:00 AM, Lance Andersen wrote:
+1
On Mar 20, 2018, at 1:57 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please help review a quick fix for a license header. Note that I
didn't change the copyright year since there's no
Hi,
Please help review a quick fix for a license header. Note that I didn't
change the copyright year since there's no code change, and also I'd
like to maintain the same copyright year as the other classes that were
added together with this class.
JBS:
Thanks! Will check it in once the CSR is approved.
Best,
Joe
On 3/12/2018 7:08 AM, Roger Riggs wrote:
Hi Joe,
Looks good
Thanks, Roger
On 3/5/2018 2:25 PM, Joe Wang wrote:
Hi,
Adding constructors with a Charset parameter for FileReader and
FileWriter. Please review.
JBS: https
a strong use case for them and re-using
file descriptors
is something that developers need to be more careful about. They
don't need the
added convenience constructors and can build readers and writers from
streams
when they need it.
Regards, Roger
On 3/5/2018 2:25 PM, Joe Wang wrote:
Hi
Hi,
Adding constructors with a Charset parameter for FileReader and
FileWriter. Please review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8183554
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8183554/webrev/
Thanks,
Joe
of documentation
where one could refer customers to.
Thanks
Christoph
-Original Message-
From: Joe Wang [mailto:huizhe.w...@oracle.com]
Sent: Mittwoch, 21. Februar 2018 21:50
To: Langer, Christoph <christoph.lan...@sap.com>
Cc: Bernd <e...@zusammenkunft.net>; OpenJDK Dev list
Hi Sherman and all,
Thanks for the further reviews!
Here's the latest webrev with boundary checks in StringLatin1/StringUTF16:
JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/
Best,
Joe
On 2/22/2018 6:07 PM, Joe Wang wrote
that splits it.
New webrev: http://cr.openjdk.java.net/~aefimov/8038043/11/01
Best,
Aleksei
On 02/22/2018 08:39 AM, Joe Wang wrote:
Hi Aleksei,
Thanks for taking the time to work on this!
Looks good overall.
XIncludeHandler: setupCurrentBaseURI method can be private.
XIncludeTextReader: there's
Looks good to me too.
Would you want to update the Copyright year? For the apache file
(ToStream.java), it would also be good to update the @LastModified tag.
Thanks,
Joe
On 2/23/2018 12:33 PM, Roger Riggs wrote:
There are two more changes in the java.xml package. (Thanks Joe)
Webrev
On 2/22/18, 12:51 PM, Xueming Shen wrote:
On 2/22/18, 12:04 PM, Joe Wang wrote:
Hi Sherman,
Thanks for reviewing the change.
Taking a local copy of the count field, but the boundary check would
be almost immediately done against the field itself. Are you worrying
about the count field may
a
local copy
and do the explicit boundary check before going into the
StringLatin1/UTF16,
especially StringUTF16. Some intrinsics, UTF16.getChar(byte[], int)
for example,
assume the caller performs bounds check (for performance reason).
-Sherman
On 2/21/18, 11:25 AM, Joe Wang wrote:
Hi Stuart
Hi Aleksei,
Thanks for taking the time to work on this!
Looks good overall.
XIncludeHandler: setupCurrentBaseURI method can be private.
XIncludeTextReader: there's a very long line at 191. It would be good to
fix it so that Sdiffs looks better the next time.
As for the tests, I'm fine with
@Joe: Is there some documentation for this change in default behavior that came
with JDK8u161? I assume it is for higher security and cannot be reverted (e.g.
by setting the feature default for Djdk.xml.overrideDefaultParser to true).
It is indeed. It was a customer's request. Customers'
SortedSet} for more information.
==
Respectively for StringBuffer. (Adjust markup to taste.)
Thanks,
s'marks
On 2/8/18 4:47 PM, Joe Wang wrote:
Hi all,
The CSR for the enhancement is now approved. Thanks Joe!
The webrev has been updated accordingly. Please let me know if you
have a
field was referenced directly in all existing uses. I've removed
the coder() method, and instead refer to the coder field directly.
StringBuffer:192: extra leading space before "}"
Fixed.
Thanks,
Joe
Thanks, Roger
On 2/8/2018 7:47 PM, Joe Wang wrote:
Hi all,
The CSR for the e
cs2.length()); i< len; i++) {
Jason
From: core-libs-dev<core-libs-dev-boun...@openjdk.java.net> on behalf of Joe
Wang<huizhe.w...@oracle.com>
Sent: Thursday, February 8, 2018 6:47 PM
To: core-libs-dev
Subject: Re: RFR (JDK11
/webrev/
Thanks,
Joe
On 2/2/2018 12:46 PM, Joe Wang wrote:
Thanks Jason. Will update that accordingly.
Best,
Joe
On 2/2/2018 11:22 AM, Jason Mehrens wrote:
Joe,
The identity check in CS.compare makes sense. However, it won't be
null hostile if we call CS.compare(null, null) and that doesn't
Thanks Lance, Roger!
Best,
Joe
On 2/2/2018 12:44 PM, Lance Andersen wrote:
go for it
On Feb 2, 2018, at 3:36 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Refer to JDK-8177561[1], XML Commons Resolver was removed from JDK
10. xmlresolver.
up with:
===
if (Objects.requireNonNull(o1) == Objects.requireNonNull(o2)) {
return 0;
}
===
Jason
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Joe Wang
<huizhe.w...@oracle.com>
Sent: Friday, February 2,
Hi,
Refer to JDK-8177561[1], XML Commons Resolver was removed from JDK 10.
xmlresolver.md therefore needs to be removed as well.
Please review:
https://bugs.openjdk.java.net/browse/JDK-8196717
http://cr.openjdk.java.net/~joehw/jdk10/8196717/webrev/
[1]
Hi,
Thanks all for comments and suggestions. I've updated the webrev. Please
review.
JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/
Thanks,
Joe
On 1/31/2018 9:31 PM, Joe Wang wrote:
Hi Tagir,
Thanks for the comment. I
Hi,
Please review an update to Xalan 2.7.2 release.
JBS: https://bugs.openjdk.java.net/browse/JDK-8193830
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8193830/webrev/index.html
Thanks,
Joe
ation) as truncation, of course,
does not zero the truncated bytes, neither does it reallocate the
array (unless explicitly asked via trimToSize).
With best regards,
Tagir Valeev.
On Fri, Jan 26, 2018 at 10:00 AM, Joe Wang<huizhe.w...@oracle.com> wrote:
Hi,
Adding methods for comparing C
Hi,
Adding methods for comparing CharSequence, StringBuilder, and StringBuffer.
The Comparable implementations for StringBuilder/Buffer are similar to
that of String, allowing comparison operations between two
StringBuilders/Buffers, e.g.
aStringBuilder.compareTo(anotherStringBuilder). For
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Sent from my iPad
On Dec 21, 2017, at 6:48 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi Lance,
Thanks for the review! As you suggested, the names in co
nstants;
/**
*
- * @author Neeraj Bajaj,k.venugo...@sun.com <mailto:k.venugo...@sun.com>
Sun Microsystems.
+ * @author Neeraj Bajaj,K Venugopal Sun Microsystems.
*/
On Dec 21, 2017, at 2:23 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
This change uses a process to strip off the @sun.com email addresses and
links, and keep just the name of the authors.
Please review:
JBS: https://bugs.openjdk.java.net/browse/JDK-8184431
webrev: http://cr.openjdk.java.net/~joehw/jdk10/8184431/webrev/index.html
Thanks,
Joe
Thanks Roger!
On 12/21/17, 9:02 AM, Roger Riggs wrote:
Hi Joe,
Looks fine
Thanks, Roger
On 12/20/2017 5:35 PM, Joe Wang wrote:
Hi,
Refer to the previous change for JDK-8191938[1], the @LastModified
tag needs to be moved to the class description section. This change
affects 341 files
Hi,
Refer to the previous change for JDK-8191938[1], the @LastModified tag
needs to be moved to the class description section. This change affects
341 files and may be hard to look through. But it's done with a script
that simply moves the tag from the top header to the class description
Thanks Roger, Alan. I've pushed the changeset after re-ran the core tests.
-Joe
On 12/12/17, 8:47 AM, Roger Riggs wrote:
Hi Joe,
Looks good; +1
Regards, Roger
On 12/11/2017 3:04 PM, Joe Wang wrote:
On 12/11/17, 11:18 AM, Roger Riggs wrote:
Hi Joe,
The new tests using testng look good
Thanks Lance!
On 12/11/17, 5:49 PM, Lance Andersen wrote:
looks OK joe
Best
Lance
On Dec 11, 2017, at 4:11 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a doc-only fix for 4 dom classes. The material change
is s/broken link/co
Hi,
Please review a doc-only fix for 4 dom classes. The material change is
s/broken link/correct link/g, that is replacing all occurrence of the
non-existent link "http://www.w3.org/TR/DOM-Level-3-Core/core.html; with
https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html.
Other
nks, Roger
On 12/8/2017 7:29 PM, Joe Wang wrote:
Thanks Roger, Alan for the comments!
I've updated the webrev accordingly. Here's the current webrev:
http://cr.openjdk.java.net/~joehw/jdk10/8183743/webrev/index.html
-Joe
On 12/4/17, 7:52 PM, Joe Wang wrote:
On 12/3/17, 11:34 AM, Alan Bat
Thanks Roger, Alan for the comments!
I've updated the webrev accordingly. Here's the current webrev:
http://cr.openjdk.java.net/~joehw/jdk10/8183743/webrev/index.html
-Joe
On 12/4/17, 7:52 PM, Joe Wang wrote:
On 12/3/17, 11:34 AM, Alan Bateman wrote:
On 01/12/2017 20:35, Joe Wang wrote
On 12/3/17, 11:34 AM, Alan Bateman wrote:
On 01/12/2017 20:35, Joe Wang wrote:
:
I think URLDecoder.decode methods should have @throws
IllegalArgumentException. I realize it's implementation specific as
to whether IAE is thrown with bad input but given that the RI does
throw IAE
On 12/1/17, 3:16 AM, Alan Bateman wrote:
On 01/12/2017 06:11, Joe Wang wrote:
Hi,
Adding convenient methods that take a Charset to several classes that
have already had methods with a Charset/Encoding name as a parameter.
To avoid any impact on compatibility and JCK tests, we've kept
, joe darcy wrote:
Looks fine Joe; good to see this work get in :-)
Thanks,
-Joe
On 11/30/2017 10:23 PM, Joe Wang wrote:
Hi all,
The webrev is updated with a javac flag that includes a set of public
APIs in java.xml that we care about with regards to doclint.
http://cr.openjdk.java.net
Hi all,
The webrev is updated with a javac flag that includes a set of public
APIs in java.xml that we care about with regards to doclint.
http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
Thanks,
Joe
On 11/30/17, 11:25 AM, Joe Wang wrote:
Hi Jon, all,
For the LastModified tag, yes
Hi,
Adding convenient methods that take a Charset to several classes that
have already had methods with a Charset/Encoding name as a parameter. To
avoid any impact on compatibility and JCK tests, we've kept the existing
methods virtually untouched except making a reference to the new ones to
938/webrev/
Thanks,
Joe
On 11/29/17, 2:11 PM, Jonathan Gibbons wrote:
Joe,
I presume javadoc is OK with this not-quite-a-doc-comment-tag, when
you do "make docs" ...
-- Jon
On 11/29/2017 10:58 AM, Joe Wang wrote:
Hi Joe,
I moved the LastModified to the bottom of the class commen
Thanks Joe, Roger!
On 11/29/17, 11:49 AM, Roger Riggs wrote:
+1
On 11/29/2017 2:45 PM, joe darcy wrote:
Hi Joe,
The new version looks fine to me; thanks,
-Joe
On 11/29/2017 10:58 AM, Joe Wang wrote:
Hi Joe,
I moved the LastModified to the bottom of the class comment block.
Please let
should *not* be
updated to include a "@LastModified: Nov 2017" comment.
Cheers,
-Joe
On 11/28/2017 10:11 AM, Joe Wang wrote:
Hi,
Please review a fix for a few more deprecation warnings. Compiling
with -Xlint:all showed that these were the last few warnings. We can
then enable
Hi,
Please review a fix for a few more deprecation warnings. Compiling with
-Xlint:all showed that these were the last few warnings. We can then
enable -Xlint:all for the java.xml module.
JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
webrevs:
Hi,
This change fixes about 300 [cast] warnings in the JAXP sources. Changes
are basically removing the redundant cast, a bit more than that only in
one case: in XSDUniqueOrKeyTraverser at line 92, uniqueOrKey was
assigned to itself when it meant to be "idc". The change didn't affect
the
al pointer to
where fallthrough happens.
Thanks,
Joe
Thanks,
-Joe
On 10/30/2017 12:17 PM, Joe Wang wrote:
On 10/30/17, 11:14 AM, Roger Riggs wrote:
Hi Joe,
+1
Is there a useful comment on the @SuppressWarnings like in other files:
XSDHandler.java: 3028
DTMDocumentImpl: 170
breaks would have been hiding bugs.
It might be worth mentioning them in the issue.
I added a note to the issue.
Thanks,
Joe
Roger
On 10/30/2017 1:09 PM, Lance Andersen wrote:
Hi Joe
The changes look OK
Best
Lance
On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.w...@oracle.com> wrot
Thanks Lance!
Best,
Joe
On 10/30/17, 10:09 AM, Lance Andersen wrote:
Hi Joe
The changes look OK
Best
Lance
On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a cleanup of fallthrough and sta
Hi,
Please review a cleanup of fallthrough and static warnings. For
fallthrough, the majority of the changes are suppressing the warnings,
while for static, replacing the instances with the class.
All jaxp tests and JCK passed.
JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
webrevs:
Thanks Lance for the super fast review!!! I haven't thought I'd check
back today :-)
On 10/23/17, 5:44 PM, Lance Andersen wrote:
looks fine Joe
On Oct 23, 2017, at 8:37 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review a fix th
Hi,
Please review a fix that cleans up [serial] warnings by adding the
serialVersionUID. The following tests showed that the serialVersionUID
for the classes in this patch have not changed from JDK 1.4 to JDK 9:
for each cls in classes that are missing serialVersionUID
for jdk
,
Overall looks good.
As we discussed, I would add a comment to NameNodeMapImpl.java
read/writeObject describing the use of Vector for backward
compatibility. No need for another webrev :-)
Best
Lance
On Oct 12, 2017, at 2:24 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@orac
fine.
Maybe do them in smaller batches next time with a consistent kind of
change. Just thought.
Thanks, Roger
On 10/12/17 11:24 AM, Joe Wang wrote:
Hi,
Please review a cleanup of rawtypes and unchecked warnings from JAXP
sources.
The patch involved a good number of classes (278
Hi,
Please review a cleanup of rawtypes and unchecked warnings from JAXP
sources.
The patch involved a good number of classes (278). However, the majority
of the changes are straight-forward replacement, e.g.
s/Vector/List[ArrayList] and their relevant methods e.g. s/elementAt/get
and etc.
_synch_object = new Object();
#16
com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java
Can this class be changed to stop using deprecated APIs instead?
#17
javax/xml/parsers/SAXParser.java
org/xml/sax/helpers/ParserAdapter.java
org/xml/sax/helpers/XMLReaderAdapter.java
Can the
Thanks Lance!
On 7/5/17, 2:13 PM, Lance Andersen wrote:
looks fine Joe
On Jul 5, 2017, at 5:11 PM, Joe Wang <huizhe.w...@oracle.com
<mailto:huizhe.w...@oracle.com>> wrote:
A quick fix as Jon suggested: replacing \u00f1 with
--- a/src/java.xml/share/classes/org/w3c/dom/ls/LSSer
A quick fix as Jon suggested: replacing \u00f1 with
--- a/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java
+++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java
@@ -136,7 +136,7 @@
* Within markup, but outside of attributes, any occurrence of a
character
* that
Hi,
This patch fixes deprecation warnings in the jaxp repo. I'm limiting the
changes to deprecation or the 102 classes. The cup-generated classes,
XPath*.java, could use some cleanup or even rewrite, but that will be
left in future works (JDK-8183580).
Most of the changes are
Hi Christoph,
We'll double-check whether there's any performance implications. Please
give us a couple of (or few) days.
Thanks,
Joe
On 1/30/17, 7:28 AM, Langer, Christoph wrote:
Hi Joe,
I've updated my webrev for 8172974 after pulling out the refactoring of
Hi Christoph,
As we discussed, let's target this for JDK 10 as a spec change at this
stage for JDK 9 is too late. Removing the namespace generation would be
another reason to do this in JDK 10 since then, we wouldn't need the
additional property.
Thanks,
Joe
On 1/31/17, 11:02 AM, Langer,
t_html.properties
-> maybe the Oracle copyright header can be inserted and the "$Id:
output_html.properties..." part can be removed?
Best regards
Christoph
-Original Message-----
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of Joe Wang
Sent: Mittw
On 12/15/16, 6:38 AM, Daniel Fuchs wrote:
On 14/12/16 00:42, Joe Wang wrote:
Thanks Christoph!
I updated the webrev for the classes you mentioned below, in a few
cases, used NetBeans' source format feature -- not for all of the
classes though (esp. the crazily large
p.8udev/>
JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/
<http://cr.openjdk.java.net/%7Eclanger/webrevs/8169112_jdk.8udev/>
Thanks & best regards
Christoph
*From:*Joe Wang [mailto:huizhe.w...@oracle.com]
*Sent:* Mittwoch, 14. Dezember 2016 21:52
*To
601 - 700 of 897 matches
Mail list logo
