+1
-Joe
On 4/29/2020 3:18 PM, naoto.s...@oracle.com wrote:
Hello,
Please review this small fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8244152
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8244152/webrev.00/
The hash map used there
Hi Fernando,
Thanks for adding coverage to this API. The change looks good overall. A
couple of comments to the test:
Line 39 instead of LocalPart, it may be better to verify the QName
themselves, I mean, assert the QNames are equal.
Line 19-21: the comment block can be moved to a @summary
+1.
Indeed, the resulting javadoc was fine :-)
Best,
Joe
On 4/27/2020 9:36 AM, naoto.s...@oracle.com wrote:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
---
Please review an update to Xerces 2.12.1. Xerces 2.12.1 was a bug fix
release. Bugs in the release were either already in the JDK or not
applicable. This patch therefore includes only an update to the md file.
--- a/src/java.xml/share/legal/xerces.md
+++ b/src/java.xml/share/legal/xerces.md
@@
Please review a doc-only change to replace links to sun.com with ones to
oracle.com. Only material changes were the two sun.com links, others
format, e.g. moving the anchor brackets to within one line.
--- a/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java
+++
+1
Best,
Joe
On 4/7/20 12:48 PM, naoto.s...@oracle.com wrote:
Thanks Roger. I will fix the typo before the push.
Naoto
On 4/7/20 12:47 PM, Roger Riggs wrote:
Hi Naoto,
Looks fine.
In EquivMapsGenerator.java.
typo:
grandfahered -> grandfathered Thanks, Roger
On 4/7/20 1:52 PM,
Naoto
On 3/30/20 2:56 PM, Joe Wang wrote:
Hi Naoto,
Thanks for the review!
I refactored the code around getting the XML version and encoding
from the locator to get rid of the CCE. The impls with EventWriter
and StreamWriter share a base class. All three classes are therefore
refactored.
rg version.
Otherwise looks good to me.
Naoto
On 3/30/20 11:02 AM, Joe Wang wrote:
Hi,
Please review a fix for the StAXResult impl. The issue was that it
output comment prior to the declaration, resulting in an invalid XML
document. The patch focuses on fixing this issue, but it does not
cover ot
Hi,
Please review a fix for the StAXResult impl. The issue was that it
output comment prior to the declaration, resulting in an invalid XML
document. The patch focuses on fixing this issue, but it does not cover
other issues the StAXResult impl may have (e.g. JDK-8241711).
JBS:
Hi Naoto,
Looks good to me.
-Joe
On 3/17/20 1:58 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8241082
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8241082/webrev.00/
It is simply
parents, unless parsing CLDR's source XML files
in the test at the runtime. I think it is enough to just ensure
there's no empty names returned at the runtime, IMO.
Naoto
On 3/13/20 5:00 PM, Joe Wang wrote:
Hi Naoto,
The existing tests verifies that a display name matches an expected
value. I
Hi Naoto,
The existing tests verifies that a display name matches an expected
value. I wonder if you'd want to do a bit more than the Boolean
assertion with a similar approach as the existing test, that is, check
that the fallback values/alias names match expected names.
Best,
Joe
On
Thanks Naoto, Lance!
-Joe
On 3/13/20 10:42 AM, Lance Andersen wrote:
+1
On Mar 13, 2020, at 1:32 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a quick fix for the missing commas after the 2nd year
in the copyright header:
diff --git
a/src/java.xml/share/cl
Please review a quick fix for the missing commas after the 2nd year in
the copyright header:
diff --git
a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java
b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java
---
The changes look good to me.
Best,
Joe
On 3/9/20 1:44 AM, Stephen Colebourne wrote:
Fine by me, but I'm not an OpenJDK Reviewer
Stephen
On Mon, 9 Mar 2020 at 03:05, wrote:
Thanks, Stephen.
Updated the webrev for those two suggestions:
http://cr.openjdk.java.net/~naoto/8239836/webrev.04/
Looks good to me.
Thanks,
Joe
On 3/3/20 10:15 AM, naoto.s...@oracle.com wrote:
Thanks, Joe. Updated:
http://cr.openjdk.java.net/~naoto/8239836/webrev.02/
Naoto
On 3/3/20 8:59 AM, Joe Wang wrote:
On 3/3/20 8:27 AM, naoto.s...@oracle.com wrote:
Hi Joe, thanks for the review.
Are you
as transitions
indirectly reflect that the offset is fixed. Your call.
Best,
Joe
Naoto
On 3/2/20 11:20 PM, Joe Wang wrote:
Hi Naoto,
The fix would be fine if you want to keep it as is since it does work.
I noticed though that for standard zones (the ones loaded from tz
database
Hi Naoto,
The fix would be fine if you want to keep it as is since it does work.
I noticed though that for standard zones (the ones loaded from tz
database), savingsInstantTransitions and standardTransitions are
consistent in that they are both empty for the standard zones, e.g.
Etc/GMT, and
+1 for the change to test/jaxp/TEST.ROOT.
Best,
Joe
On 2/13/20 10:08 AM, Igor Ignatev wrote:
Oh, I’m sorry I actually changed it to 5.0 when were (re)doing testing, and
apparently forgot to replace the webrev, the right is
http://cr.openjdk.java.net/~iignatyev//8238943/webrev.01 ; with
+1. That's nicer.
-Joe
On 2/11/20 10:17 AM, naoto.s...@oracle.com wrote:
Hi,
I modified the proposed changeset. Removed the hard coded 3-letter id
compatibility mappings (oldMappings) from CLDRConverter.java. Instead,
using public ZoneId.SHORT_IDS that contain the same set of mappings
Hi Naoto,
I see the existing tests were changed, e.g. the abbreviation / short
timezone name, the result of calling getDisplayName. Would you need a
CSR to discuss/document the potential incompatibility?
Best,
Joe
On 2/7/20 1:44 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the
+1
Best,
Joe
On 2/6/20 8:50 AM, naoto.s...@oracle.com wrote:
Hello,
Please review this extra small fix for this issue:
https://bugs.openjdk.java.net/browse/JDK-8238605
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8238605/webrev.00/
It is simply updating the
Thanks Daniel!
-Joe
On 1/17/20 3:57 AM, Daniel Fuchs wrote:
On 16/01/2020 18:22, Joe Wang wrote:
It's because the class itself is declared final (at least on the few
files I've taken a look), so final on a method is redundant.
Ah! I had missed that. Thaks Rémi!
Meanwhile, I noticed I
On 1/17/20 10:31 AM, naoto.s...@oracle.com wrote:
Hi Leo,
The l10n files for HelpResources_*.properties in jpackage discard the
format in the original English resource file where lines are nicely
aligned. Can you please preserve the format?
Also, I find it odd to observe duplicated
Thanks Lance, again :-)
-Joe
On 1/16/20 2:39 PM, Lance Andersen wrote:
Hi Joe,
The additions look OK also
Best
Lance
On Jan 16, 2020, at 1:22 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
On 1/16/20 9:50 AM, Remi Forax wrote:
- Mail original -----
De:
On 1/16/20 9:50 AM, Remi Forax wrote:
- Mail original -
De: "Joe Wang"
À: "Daniel Fuchs" , "core-libs-dev"
Envoyé: Jeudi 16 Janvier 2020 18:40:18
Objet: Re: RFR [15/java.xml] 8235368 : Update BCEL to Version 6.4.1
On 1/16/20 2:35 AM, Daniel Fuchs w
in java.xml.
Best regards,
Joe
best regards,
-- daniel
On 14/01/2020 20:08, Joe Wang wrote:
Hi,
Please review an update to BCEL 6.4.1.
JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
webrev:
http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
Similar approach as the la
Thanks Lance!
-Joe
On 1/15/20 2:21 PM, Lance Andersen wrote:
Hi Joe,
This seems OK.
On Jan 14, 2020, at 3:08 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review an update to BCEL 6.4.1.
JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
web
On 1/14/20 6:04 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Thank you for the review. Please find my comments below:
On 1/14/20 3:35 PM, Joe Wang wrote:
Hi Naoto,
Since it's dealing with non-standard properties files, is there a
need to verify the files? The constructor (HijrahChronology
Hi Naoto,
Since it's dealing with non-standard properties files, is there a need
to verify the files? The constructor (HijrahChronology) does check
whether the id or type is empty. If there is no existing process to
validate, it's probably not worth it to spend time as it's rare and it's
Performance test results show no regression over the current build (15-b5).
-Joe
On 1/14/20 12:08 PM, Joe Wang wrote:
A performance test is running.
Hi,
Please review an update to BCEL 6.4.1.
JBS: https://bugs.openjdk.java.net/browse/JDK-8235368
webrev: http://cr.openjdk.java.net/~joehw/jdk15/8235368/webrev/index.html
Similar approach as the last update:
1. Format
All format changes are kept as they are in the source in order to
I see. It's all good to me then.
Best,
Joe
On 1/10/20 4:04 PM, naoto.s...@oracle.com wrote:
Hi Joe,
That data file seems no longer included in the ICU4J package (as of
64.2), thus I left it as it is.
Naoto
On 1/10/20 2:57 PM, Joe Wang wrote:
Is there a reason why uidna.spp was left out
Is there a reason why uidna.spp was left out of the move?
-Joe
On 1/10/20 2:02 PM, naoto.s...@oracle.com wrote:
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8174270
The proposed changeset is located at:
. So there seems to be no explicit reason (to be
noted in the source code) for not syncing.
My $.02
Naoto
On 1/3/20 11:40 AM, Joe Wang wrote:
Hi Naoto,
The change looks fine to me as only monetaryGroupingSeparator was
added to equals.
I can't help to note though that, all fields
code in
DecimalFormatSymbols needs to be recalculated when any of the relevant
fields is mutated. Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8227313/webrev.02/
Naoto
On 1/2/20 2:19 PM, Joe Wang wrote:
Happy New Year, Naoto!
Thanks for the explanation and changes
Happy New Year, Naoto!
Thanks for the explanation and changes. The changeset looks good to me.
-Joe
On 1/2/20 12:50 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Happy new year and thanks for your comments. Please see my replies below:
On 12/23/19 5:20 PM, Joe Wang wrote:
Hi Naoto
Hi Naoto,
Is there a need for an APINote to note the relationship between the new
get/setMonetaryGroupingSeparator and get/setGroupingSeparator methods.
The new method did state it "May be different from {@code grouping
separator} in some locales", but that may be insufficient. For example,
On 12/12/19 10:46 PM, Igor Ignatyev wrote:
@Joe/Lance,
were there any reasons why you needed to switch jtreg's
requiredVersion back to 4.2b13 in jaxp? are there any reasons which
prevent jaxp from switching to jtreg4.2b16 now?
I don't recall any specific reason, if any. It would be fine
, Roger Riggs wrote:
+1
There's quite a bit of work being done to get the eligible stings
as part of each parse but it doesn't look easy to re-use it acrosses
parses.
Roger
On 12/12/19 3:42 PM, Joe Wang wrote:
On 12/12/19 12:31 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Thank you
. The
changes look good to me then.
Best,
Joe
Naoto
On 12/12/19 11:32 AM, Joe Wang wrote:
Hi Naoto,
Does the new code block, 4156 - 4174, need a conditional statement,
that is when it's for a standard timezon? Before this change, or
before a custom TimeZoneNameProvider is attempted, the process didn't
Hi Naoto,
Does the new code block, 4156 - 4174, need a conditional statement, that
is when it's for a standard timezon? Before this change, or before a
custom TimeZoneNameProvider is attempted, the process didn't need to
loop through regionIds to add display names.
Thanks,
Joe
On 12/11/19
+1, looks good!
Best regards,
Joe
On 12/5/19 12:13 PM, Roger Riggs wrote:
Hi Naoto,
Thanks for the updates.
Looks fine.
Roger
On 12/5/19 1:49 PM, naoto.s...@oracle.com wrote:
Thanks, Joe and Roger, for the reviews. Here is the updated webrev:
Hi Naoto,
Looks good. I understand you'll update the webrev (with the added
statement to readObject) once the CSR is approved.
ResourceBundleGenerator.java might have been accidentally touched as
there's no change there.
I wonder if you need to guard the pluralRules input since you're
Thanks Lance!
-Joe
On 11/21/19 3:59 PM, Lance Andersen wrote:
Hi Joe,
Looks OK overall.
Best
Lance
On Nov 20, 2019, at 4:48 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Hi,
Please review an update to Java CUP. This is an effort to move to the
latest version, v0.11b. JCU
Hi,
Please review an update to Java CUP. This is an effort to move to the
latest version, v0.11b. JCUP is used by Xalan to generate XPathParser.
Included in the JDK are runtime classes and XPathParser. In CUP 0.11b,
the main additions to the runtime were SymbolFactory and ComplexSymbol
that
: Freitag, November 8, 2019 11:14 AM
An: Joe Wang
Cc: core-libs-dev
Betreff: Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount
of memory
Hi Joe,
Fix looks OK to me , but i am not able to understand how come
"NamespaceMappings" instance can increase memory uses from (20M
Please review a quick fix that reduces unnecessary object allocations.
JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/
Thanks,
Joe
modified the JIRA issue
mentioning it, so that maintainers later could find out the rationale.
Naoto
On 11/6/19 6:21 PM, Joe Wang wrote:
Looks good to me. It might be good to leave a note to the method
about the change (e.g. why it no longer substitutes).
-Joe
On 11/6/19 1:45 PM, naoto.s
Looks good to me. It might be good to leave a note to the method about
the change (e.g. why it no longer substitutes).
-Joe
On 11/6/19 1:45 PM, naoto.s...@oracle.com wrote:
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8233579
The proposed
+1. Thanks Aleksei!
-Joe
On 10/21/19 6:09 AM, Aleks Efimov wrote:
Hi,
The BCEL version has been updated to 6.3.1 by JDK-8224157 [1]. The
BCEL license file needs to be updated to include the correct version.
Webrev: http://cr.openjdk.java.net/~aefimov/8232713/00
JBS:
Thanks Lance!
On 9/27/19 10:47 AM, Lance Andersen wrote:
Hi Joe,
The change looks fine as does the test.
Best
Lance
On Sep 27, 2019, at 12:29 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a fix to the NPE issue. This is part of the work on the
XML declaratio
Please review a fix to the NPE issue. This is part of the work on the
XML declaration related issues.
JBS: https://bugs.openjdk.java.net/browse/JDK-8016914
webrev: http://cr.openjdk.java.net/~joehw/jdk14/8016914/webrev/
Thanks,
Joe
Thanks Alan!
Joe
On 9/20/19 10:03 AM, Alan Bateman wrote:
On 20/09/2019 17:46, Joe Wang wrote:
Thanks Alan!
Here's the updated webrev after changing the apiNote as you suggested:
http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev02/index.html
Looks good.
Thanks Alan!
Here's the updated webrev after changing the apiNote as you suggested:
http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev02/index.html
-Joe
On 9/20/19 9:07 AM, Alan Bateman wrote:
On 20/09/2019 06:15, Joe Wang wrote:
Thanks Lance!
Yes, saw them typos :-) Also removed
Thanks Lance! It's a cleanup on top of cleanup :-)
On 9/20/19 4:13 AM, Lance Andersen wrote:
Round 2 even looks cleaner :-)
On Sep 20, 2019, at 1:15 AM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Thanks Lance!
Yes, saw them typos :-) Also removed the extra space i
Joe,
Overall this looks good and also cleans up a couple of typos :-)
One nit in both package-info @apiNote, you will notice an extra space
before the was which could be removed before you push
Best
Lance
On Sep 19, 2019, at 8:00 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a follow-up doc clarification patch after 8230814 [1]. In
this patch, the statement with a reference to the SAX project is moved
to an apiNote in package/sub-package description to reflect the fact
that it is a historical note in nature. The license related text that
appears in
On 9/17/19 3:00 AM, Alan Bateman wrote:
On 16/09/2019 19:25, Joe Wang wrote:
:
I deliberately left the javadoc in the SAX package as they are. But I
agree it may be worth it to address this aspect of the document. I
suggest we do so with a separate doc-only request[1] to clarify
On 9/14/19 1:08 AM, Alan Bateman wrote:
On 13/09/2019 21:50, Joe Wang wrote:
:
It can be said that the SAX project, in terms of the API work, was
dead a long time ago. There hasn't been any updates/changes since SAX
2.0.2 released in 2004[1]. SAX is in public domain [2]. Sun/Oracle
On 9/13/19 12:20 PM, Alan Bateman wrote:
On 13/09/2019 19:53, Joe Wang wrote:
Please review a new method addition to SAX ContentHandler that allows
a SAX parser to send back information about the declaration of the
input document.
JBS: https://bugs.openjdk.java.net/browse/JDK-8230814
CSR
Please review a new method addition to SAX ContentHandler that allows a
SAX parser to send back information about the declaration of the input
document.
JBS: https://bugs.openjdk.java.net/browse/JDK-8230814
CSR: https://bugs.openjdk.java.net/browse/JDK-8230824
webrev:
+1, looks good to me.
Best regards,
Joe
On 9/10/19 2:20 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8230136
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8230136/webrev.00/
The fix
Thanks Lance! I did a re-run of all tests and they all passed.
-Joe
On 9/4/19 12:12 PM, Lance Andersen wrote:
Hi Joe
+1
On Sep 4, 2019, at 1:30 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a patch that removes some warnings and errors printed
out to th
Please review a patch that removes some warnings and errors printed out
to the console.
JBS: https://bugs.openjdk.java.net/browse/JDK-8228854
CSR: https://bugs.openjdk.java.net/browse/JDK-8228973
webrev: http://cr.openjdk.java.net/~joehw/jdk14/8228854/webrev/
Thanks,
Joe
On 8/28/19 8:12 AM, Lance Andersen wrote:
Hi Joe,
The change and test look OK
Thanks Lance!
On Aug 27, 2019, at 1:20 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a patch for an issue where a custom impl of
XMLStreamWriter caused a CCE. The problem was
Please review a patch for an issue where a custom impl of
XMLStreamWriter caused a CCE. The problem was that our implementation
was changed to an internally extended interface. We could consider
making it external, but for now, we'll do with a check.
Note that there's no material change in
Hi Frank,
Thanks for fixing this. How did you find this out? Are you running some
kind of tools? I hope that's the case since then we could be sure there
were no other cases in the test suite.
The patch looks good. It's fortunate we haven't broken anything ;-) The
test passed just fine.
Thanks Lance!
On 8/22/19 9:56 AM, Lance Andersen wrote:
Hi Joe,
This looks good overall.
Best
Lance
On Aug 21, 2019, at 9:31 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a specification claraficaiton/doc-only change to
ErrorHandler and ContentHandler.
J
Please review a specification claraficaiton/doc-only change to
ErrorHandler and ContentHandler.
JBS: https://bugs.openjdk.java.net/browse/JDK-8229388
CSR: https://bugs.openjdk.java.net/browse/JDK-8229738
webrev: http://cr.openjdk.java.net/~joehw/jdk14/8229388/webrev/
Thanks,
Joe
l Fuchs wrote:
Hi Joe,
On 14/08/2019 20:15, Joe Wang wrote:
The 2nd part is not necessary as that's what the "@throws" tag is for.
Not withstanding the fact that this is a copy of the API doc from
java.lang.Math, I'd argue that the second part is quite important.
It's why the method i
while you're here, could you please replace semicolon with comma:
916 * Returns the value of the {@code long} argument;
917 * throwing an exception if the value overflows an {@code int}.
It seems to me the first sentence shall be the synopsis. The 2nd part is
not necessary as
Thanks Lance!
-Joe
On 7/25/19 4:04 PM, Lance Andersen wrote:
Hi Joe
The change looks reasonable :-)
On Jul 25, 2019, at 6:28 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a quite fix in a validation source where a String
comparison was made as references.
J
Please review a quite fix in a validation source where a String
comparison was made as references.
JBS: https://bugs.openjdk.java.net/browse/JDK-8068376
webrev: http://cr.openjdk.java.net/~joehw/jdk14/8068376/webrev/
Thanks,
Joe
Looks all good Naoto :-)
-Joe
On 7/25/19 2:35 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Yes, I only removed not in-use files, i.e., 2 & 4. I sent the previous
email just after confirming that all tests (open/closed) passed on a
platform :-)
Naoto
On 7/25/19 2:24 PM, Joe Wang wrote:
Roger
On 7/24/19 6:24 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Thank you for the review.
On 7/24/19 2:57 PM, Joe Wang wrote:
Hi Naoto,
The method findNegativeSavings method in TzdbZoneRulesProvider.java
states that it "Find the minimum negative savings". While the
result is correct
Thanks Naoto. Looks good.
-Joe
On 7/24/19 3:24 PM, naoto.s...@oracle.com wrote:
Hi Joe,
Thank you for the review.
On 7/24/19 2:57 PM, Joe Wang wrote:
Hi Naoto,
The method findNegativeSavings method in TzdbZoneRulesProvider.java
states that it "Find the minimum negative savings&qu
Hi Naoto,
The method findNegativeSavings method in TzdbZoneRulesProvider.java
states that it "Find the minimum negative savings". While the result is
correct since the rules all have the same value for SAVE, I wonder if
that's ideal conceptually. Given a start LDT, shouldn't it be looking
Thanks Lance!
On 7/18/19 3:06 PM, Lance Andersen wrote:
+1
On Jul 18, 2019, at 1:40 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a patch to eliminate the [Fatal Error] message printed
out to the console. Whether the parser should have written the error
out in
Please review a patch to eliminate the [Fatal Error] message printed out
to the console. Whether the parser should have written the error out in
the first place is up to debate, not covered in this patch, but when the
request is for the Transformer to handle errors through a registered
Thanks Lance!
On 7/16/19 12:20 PM, Lance Andersen wrote:
Looks OK Joe
On Jul 16, 2019, at 12:34 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a fix for the uniqueness constraint. The fix is at line
403 where the variable for tracking matches is reset. Without t
Please review a fix for the uniqueness constraint. The fix is at line
403 where the variable for tracking matches is reset. Without the reset,
subsequent matches would have been skipped, thus not catching duplicate
values.
As the report's workaround indicated, this issue was fixed in Apache
+1
-Joe
On 7/11/19 11:32 PM, Frank Yuan wrote:
Hi
Would you like to review the following patch for
Bug: https://bugs.openjdk.java.net/browse/JDK-8227438
--- a/test/lib/jdk/test/lib/util/FileUtils.java Thu Jul 11 15:58:54 2019
+
+++
Thanks Lance!
-Joe
On 7/10/19 6:38 PM, Lance Andersen wrote:
+1
On Jul 10, 2019, at 7:57 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a cleanup that removes unused code. This code has two
errors, one as indicated in the bug report, another attempting to
loo
Please review a cleanup that removes unused code. This code has two
errors, one as indicated in the bug report, another attempting to loop
through allVarsEverDeclared that was just created (meaning size=0). It
just ensures again that the code was never used.
JBS:
, but no big deal and
does not need changed prior to pushing.
Thanks. I'm going to keep them this way then ;-) They are small enough.
-Joe
On Jul 9, 2019, at 5:17 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a fix for an Exception caused by StAXSource. The fix
Please review a fix for an Exception caused by StAXSource. The fix adds
code that processes the prolog and misc content as specified by the XML
specification, and removes the code that made incorrect assumption about
XML document structure.
https://bugs.openjdk.java.net/browse/JDK-7148925
Thanks Lance!
-Joe
On 7/2/19, 10:22 AM, Lance Andersen wrote:
Looks OK to me Joe
On Jul 2, 2019, at 11:51 AM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Thanks Daniel. That test case is added.
Best,
Joe
On 7/2/19, 1:21 AM, Daniel Fuchs wrote:
Hi Joe,
I haven't spotted
Thanks Daniel!
On 7/2/19, 9:16 AM, Daniel Fuchs wrote:
Hi Joe,
On 02/07/2019 17:51, Joe Wang wrote:
Thanks Daniel. That test case is added.
LGTM!
best regards,
-- daniel
Best,
Joe
On 7/2/19, 1:21 AM, Daniel Fuchs wrote:
Hi Joe,
I haven't spotted anything obviously wrong
On 7/2/19, 1:23 AM, Daniel Fuchs wrote:
Oh, and BTW is the change to PrettyPrintTest.java intended?
(the removal of the line:
385 dbf.setValidating(true);
seems to be the only change)
Yes. The only effect of setting validating without an ErrorHandler was
producing lots of warnings
Maybe the test could have a test case for that specific example too?
Just to make sure whitespaces in CDATA aren't eaten away?
best regards,
-- daniel
On 01/07/2019 20:46, Joe Wang wrote:
Please review a fix to xml pretty print. This is a regression
introduced during the JDK 9 development. CDATA is
Please review a fix to xml pretty print. This is a regression introduced
during the JDK 9 development. CDATA is marked up to be interpreted
literally as textual data, in other words, it's still character data.
The processor therefore shall treat it as text data. The content of
"abcxyz" should
On 6/24/19, 12:00 PM, Daniel Fuchs wrote:
On 24/06/2019 18:24, Joe Wang wrote:
Keeping the code in sync with the BCEL (not perfect) source is in our
interest to produce smaller changeset in any future updates. Would
you be okay with the current webrevs?
Yes. This was just a remark
On 6/24/19, 2:23 AM, Daniel Fuchs wrote:
On 21/06/2019 21:20, Joe Wang wrote:
Full webrev (for the record)
http://cr.openjdk.java.net/~joehw/jdk13/8224157/webrev_02/
A short version of webrev_02 that includes the only files mentioned
in this review:
http://cr.openjdk.java.net/~joehw/jdk13
Thanks Lance!
Joe
On 6/21/19, 1:59 PM, Lance Andersen wrote:
The revised webrev looks fine Joe
On Jun 21, 2019, at 4:20 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
On 6/21/19, 11:59 AM, Daniel Fuchs wrote:
Hi Joe,
I promise, I will not grumble about the formatting
On Jun 20, 2019, at 6:45 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review an update to BCEL 6.3.1. This changeset will go into
JDK13 if approved, 14 if not.
1. Format
The changeset looks big, the majority of the changes however were
only different in fo
/8224157/webrev_02_short/
I'm re-running all tests.
Best regards,
Joe
best regards,
-- daniel
On 20/06/2019 23:45, Joe Wang wrote:
Please review an update to BCEL 6.3.1. This changeset will go into
JDK13 if approved, 14 if not.
1. Format
The changeset looks big, the majority
Please review an update to BCEL 6.3.1. This changeset will go into JDK13
if approved, 14 if not.
1. Format
The changeset looks big, the majority of the changes however were
only different in format (i.e. Const.java). Unlike previous updates, I'm
leaving the format as they are in the
Thanks Lance! Pushed. Let's hope the performance will be back to normal
in the next build.
Best,
Joe
On 5/24/19, 10:18 AM, Lance Andersen wrote:
+1
On May 24, 2019, at 1:11 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote:
Please review a fix to the performance regression i
Please review a fix to the performance regression introduced by Xerces
update. The performance benchmark gives weight to small XML files. Large
chunk sizes are therefore not helpful. Performance tests with the
following patch showed that the results are on par with that for JDK 13 b18.
401 - 500 of 897 matches
Mail list logo
