Integrated: 8285081: Improve XPath operators count accuracy
On Fri, 3 Jun 2022 18:17:55 GMT, Joe Wang wrote: > Adjust how XPath operators are counted to improve accuracy. This change does > not affect how XPath works. > > Test: > Tier2 passed; > JCK XML tests passed. This pull request has now been integrated. Changeset: 8e078391 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/8e0783917975075aae5d586f0076d5093afb0b62 Stats: 63 lines in 3 files changed: 40 ins; 3 del; 20 mod 8285081: Improve XPath operators count accuracy Reviewed-by: naoto, lancea - PR: https://git.openjdk.java.net/jdk/pull/9022
Re: RFR: 8285081: Improve XPath operators count accuracy [v3]
> Adjust how XPath operators are counted to improve accuracy. This change does > not affect how XPath works. > > Test: > Tier2 passed; > JCK XML tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove unused parameter - Changes: - all: https://git.openjdk.java.net/jdk/pull/9022/files - new: https://git.openjdk.java.net/jdk/pull/9022/files/e1e3deb2..6dc1cc2c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9022=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9022=01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/9022.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9022/head:pull/9022 PR: https://git.openjdk.java.net/jdk/pull/9022
Re: RFR: 8285081: Improve XPath operators count accuracy [v2]
On Fri, 3 Jun 2022 21:52:08 GMT, Naoto Sato wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review update
>
> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java
> line 377:
>
>> 375: else if ((Token.LPAREN != c) && (Token.LBRACK != c) &&
>> (Token.RPAREN != c)
>> 376: && (Token.RBRACK != c) && (Token.COLON != c) &&
>> (Token.COMMA != c)) {
>> 377: if (Token.STAR == c) {
>
> Could be
>
> if (Token.STAR != c || !isAxis) {
> incrementCount(c);
> }
Thanks Naoto! Updated as commented.
-
PR: https://git.openjdk.java.net/jdk/pull/9022
Re: RFR: 8285081: Improve XPath operators count accuracy [v2]
> Adjust how XPath operators are counted to improve accuracy. This change does > not affect how XPath works. > > Test: > Tier2 passed; > JCK XML tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: review update - Changes: - all: https://git.openjdk.java.net/jdk/pull/9022/files - new: https://git.openjdk.java.net/jdk/pull/9022/files/f840e840..e1e3deb2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9022=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9022=00-01 Stats: 13 lines in 2 files changed: 4 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/9022.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9022/head:pull/9022 PR: https://git.openjdk.java.net/jdk/pull/9022
Re: RFR: 8285081: Improve XPath operators count accuracy
On Fri, 3 Jun 2022 21:11:20 GMT, Naoto Sato wrote:
>> Adjust how XPath operators are counted to improve accuracy. This change does
>> not affect how XPath works.
>>
>> Test:
>> Tier2 passed;
>> JCK XML tests passed.
>
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java
> line 99:
>
>> 97: public static final int[] OPERATORS = {GT, GE, EQ, NE, LT, LE, SLASH,
>> DSLASH,
>> 98: DOT, DDOT, ATSIGN, DCOLON, PLUS, MINUS, STAR, DIV, MOD, AND, OR,
>> LPAREN,
>> 99: LBRACK, VBAR, DOLLAR, NODE, TEXT, PI, PIPARAM};
>
> Any reason for re-shuffling the order of operators? I'd expect new ones are
> appended to the existing ones, or appear in the order of their declarations
> above?
> (or is this automatically generated, as described in the comment?)
The order is not significant for this process as the lexer takes care of
creating the right symbol. I re-grouped them to put operators of the same
category together so that it's easier to see what might be missing.
> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java
> line 476:
>
>> 474: }
>> 475:
>> 476: private void incrementCount(char c) {
>
> `c` is not used.
Will remove it.
-
PR: https://git.openjdk.java.net/jdk/pull/9022
Re: RFR: 8285081: Improve XPath operators count accuracy
On Fri, 3 Jun 2022 21:08:04 GMT, Naoto Sato wrote: >> Adjust how XPath operators are counted to improve accuracy. This change does >> not affect how XPath works. >> >> Test: >> Tier2 passed; >> JCK XML tests passed. > > src/java.xml/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java > line 152: > >> 150: private int opCount = 0; >> 151: private int totalOpCount = 0; >> 152: private int lastSym; > > `lastSym` is never initialized. It's OK for the first time, but should this > be reset for the next use (if any), e.g. somewhere around line 595? Right, -1 would be appropriate as 0 indicates EOF. - PR: https://git.openjdk.java.net/jdk/pull/9022
RFR: 8285081: Improve XPath operators count accuracy
Adjust how XPath operators are counted to improve accuracy. This change does not affect how XPath works. Test: Tier2 passed; JCK XML tests passed. - Commit messages: - 8285081: Improve XPath operators count accuracy Changes: https://git.openjdk.java.net/jdk/pull/9022/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9022=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285081 Stats: 66 lines in 3 files changed: 43 ins; 3 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/9022.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9022/head:pull/9022 PR: https://git.openjdk.java.net/jdk/pull/9022
Re: RFR: 8287340: Refactor old code using StringTokenizer in locale related code
On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato wrote: > Refactoring some old code in locale providers. The test case data have also > been modified due to: > - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not > handle the case for `no-NO-NY`. > - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` > and falls back, so comparing locales using language tags does not work for > those locales. Changed to compare with `Locale.toString()` instead. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8960
Integrated: 8284400: Improve XPath exception handling
On Fri, 27 May 2022 01:12:18 GMT, Joe Wang wrote: > Addresses an insufficiency of error handling in the XPath implementation. > Some cleanup where appropriate, without attempting to do too much as this is > a component that hasn't had much changes for 15 years, a fairly stable > application. > > Test: tier2 passed > JCK: JCK XML tests passed This pull request has now been integrated. Changeset: ed8e8ac2 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/ed8e8ac2892af3a0a70b95330e01ec976d3fea3c Stats: 863 lines in 11 files changed: 617 ins; 179 del; 67 mod 8284400: Improve XPath exception handling Reviewed-by: lancea, naoto - PR: https://git.openjdk.java.net/jdk/pull/8910
Re: RFR: 8284400: Improve XPath exception handling
On Fri, 27 May 2022 01:12:18 GMT, Joe Wang wrote: > Addresses an insufficiency of error handling in the XPath implementation. > Some cleanup where appropriate, without attempting to do too much as this is > a component that hasn't had much changes for 15 years, a fairly stable > application. > > Test: tier2 passed > JCK: JCK XML tests passed Thanks Lance, Naoto! Updated copyright year and LastModified tag. - PR: https://git.openjdk.java.net/jdk/pull/8910
Re: RFR: 8284400: Improve XPath exception handling [v2]
> Addresses an insufficiency of error handling in the XPath implementation. > Some cleanup where appropriate, without attempting to do too much as this is > a component that hasn't had much changes for 15 years, a fairly stable > application. > > Test: tier2 passed > JCK: JCK XML tests passed Joe Wang has updated the pull request incrementally with one additional commit since the last revision: update copyright year and LastModified tag - Changes: - all: https://git.openjdk.java.net/jdk/pull/8910/files - new: https://git.openjdk.java.net/jdk/pull/8910/files/a03cb0d4..12575c95 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8910=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8910=00-01 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8910.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8910/head:pull/8910 PR: https://git.openjdk.java.net/jdk/pull/8910
RFR: 8284400: Improve XPath exception handling
Address some insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is an component that hasn't had much changes for 15 years, a fairly stable application. - Commit messages: - 8284400: Improve XPath exception handling Changes: https://git.openjdk.java.net/jdk/pull/8910/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8910=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284400 Stats: 861 lines in 11 files changed: 617 ins; 179 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/8910.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8910/head:pull/8910 PR: https://git.openjdk.java.net/jdk/pull/8910
Re: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2]
On Wed, 25 May 2022 17:15:18 GMT, Naoto Sato wrote: >> Refactoring the leftover self-calculations of the optimized `HashMap` >> initial value with `newHashMap()` method. Also replaced some string literals >> using text blocks for better readability. Confirmed that the output resource >> bundle sources are effectively (sans indentation) the same as the original >> ones. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > minor fixup Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8887
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 13 additional commits since > the last revision: > > - Merge branch 'master' into JDK-8279185 > - Addressing review comments > - Revert to use the default method > - Removed unnecessary package names > - Modified class desc of `IsoFields` > - abstract class -> top level interface > - interface -> abstract class > - Removed the method > - Changed to use a type to determine ISO based or not > - Renamed the new method > - ... and 3 more: > https://git.openjdk.java.net/jdk/compare/3b1d6d84...3f69909f Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8284213: Replace usages of 'a the' in xml
On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/the… > > I tried to avoid changing external libraries, there are quite a few such > typos. > Let me know if I should revert any files. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8769
Integrated: 8282280: Update Xerces to Version 2.12.2
On Mon, 16 May 2022 19:34:11 GMT, Joe Wang wrote: > Update to Xerces 2.12.2. > > The update also fixes JDK-8144117. Added a test. > > Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this > update. See related issue report. This pull request has now been integrated. Changeset: 72bd41b8 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/72bd41b844e03da4bcb19c2cb38d96975a9ebceb Stats: 310 lines in 17 files changed: 296 ins; 3 del; 11 mod 8282280: Update Xerces to Version 2.12.2 Reviewed-by: lancea, naoto - PR: https://git.openjdk.java.net/jdk/pull/8732
Re: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]
On Mon, 16 May 2022 21:54:52 GMT, Naoto Sato wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> provider description
>
> test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 48:
>
>> 46: */
>> 47: public class SchemaTest {
>> 48: private static final String XSD_8144117 = "\n" +
>
> If it is not from the upstream Xerces test but our own, can we utilize text
> blocks here?
Our source level is still generally 8. The expectation is also that this patch
will be backported.
> test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 79:
>
>> 77:
>> 78: /*
>> 79: * DataProvider: valid xsd
>
> This comment is the same as the above provider. Can we change it to a more
> meaningful one?
Updated with a bit more description.
-
PR: https://git.openjdk.java.net/jdk/pull/8732
Re: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]
> Update to Xerces 2.12.2. > > The update also fixes JDK-8144117. Added a test. > > Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this > update. See related issue report. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: provider description - Changes: - all: https://git.openjdk.java.net/jdk/pull/8732/files - new: https://git.openjdk.java.net/jdk/pull/8732/files/ae224c6d..db91b60e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8732=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8732=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8732/head:pull/8732 PR: https://git.openjdk.java.net/jdk/pull/8732
Re: RFR: 8282280: Update Xerces to Version 2.12.2
On Mon, 16 May 2022 19:34:11 GMT, Joe Wang wrote: > Update to Xerces 2.12.2. > > The update also fixes JDK-8144117. Added a test. > > Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this > update. See related issue report. Thanks Lance. Yes, I've notified the JCK team, will wait till they've resolved the issue (or at least put them in the known list). Meanwhile, just want to get the patch reviewed. - PR: https://git.openjdk.java.net/jdk/pull/8732
RFR: 8282280: Update Xerces to Version 2.12.2
Update to Xerces 2.12.2. The update also fixes JDK-8144117. Added a test. Tests: local XML tests passed. Tier2 running. Two JCK tests failed with this update. See related issue report. - Commit messages: - 8282280: Update Xerces to Version 2.12.2 Changes: https://git.openjdk.java.net/jdk/pull/8732/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8732=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282280 Stats: 310 lines in 17 files changed: 296 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8732/head:pull/8732 PR: https://git.openjdk.java.net/jdk/pull/8732
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Mon, 16 May 2022 18:23:23 GMT, Naoto Sato wrote: > Do not enclose the skara command within backquotes. Thanks Naoto! I didn't realize that's what he did :-) - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Mon, 16 May 2022 16:35:16 GMT, Shruthi wrote: > `/integrate` There may be sth. with your input, it's not recognized as Git command. Try again, or copy this command instead. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Mon, 16 May 2022 16:26:41 GMT, Shruthi wrote: > `integrate` I think you missed slash, it's slash integrate. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Fri, 13 May 2022 18:51:47 GMT, Joe Wang wrote: >> Shruthi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new commit since the last revision: >> >> Modify copyright year > > Did you mean the failure (Pre-submit tests - Linux x86 - Test (tier1) ) > above? That's not related to your change. > @JoeWang-Java Yes. Shall I comment as **integrate** then? Yes, please go ahead with integrate. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools
On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking > Adam's patch. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8706
Re: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools
On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote:
> Applied required casts for the upcoming warning. Verified by cherry-picking
> Adam's patch.
make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
line 1278:
> 1276: state[numCategories] |= (short) END_STATE_FLAG;
> 1277: if (sawEarlyBreak) {
> 1278: state[numCategories] |= LOOKAHEAD_STATE_FLAG;
Does this need a cast as well? and also other cases, e.g. line 1019:
state[numCategories] = DONT_LOOP_FLAG;?
-
PR: https://git.openjdk.java.net/jdk/pull/8706
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Thu, 12 May 2022 18:02:26 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has refreshed the contents of this pull request, and previous commits > have been removed. The incremental views will show differences compared to > the previous content of the PR. The pull request contains one new commit > since the last revision: > > Modify copyright year Did you mean the failure (Pre-submit tests - Linux x86 - Test (tier1) ) above? That's not related to your change. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Thu, 12 May 2022 18:02:26 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has refreshed the contents of this pull request, and previous commits > have been removed. The incremental views will show differences compared to > the previous content of the PR. The pull request contains one new commit > since the last revision: > > Modify copyright year They all look good now. Thanks. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v7]
On Wed, 11 May 2022 05:22:22 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has updated the pull request incrementally with one additional commit > since the last revision: > > Modify copyright year Copyright years for XRTreeFragSelectWrapper.java and XSLTErrorResources.java were still not updated, with the later missing the LastModified tag. Please double check all files before integrate. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v5]
On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato wrote: >> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support >> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. >> Corresponding CSR is also being drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains six additional commits since > the last revision: > > - Disallow `UTC` -> `GMT` > - Merge branch 'master' into JDK-8285844 > - Minor fixup > - Allowed round-trips for offset-style ZoneIds. > - Fixed offsets in milliseconds, added test variations, refined Custom ID > definitions > - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all > ZoneOffsets and returns GMT unexpected Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8606
Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v4]
On Wed, 11 May 2022 17:04:41 GMT, Naoto Sato wrote:
>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support
>> second-level resolution, enabling round trips with `java.time.ZoneOffset`s.
>> Corresponding CSR is also being drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Minor fixup
src/java.base/share/classes/java/util/TimeZone.java line 80:
> 78: * {@code GMT} Sign Hours {@code :} Minutes
> {@code :} Seconds
> 79: * {@code GMT} Sign Hours {@code :} Minutes
> 80: * {@code GMT} Sign Hours Minutes
For hours and minutes, the format can be hh:mm or hhmm. Is it worth it to
support hhmmss as well?
-
PR: https://git.openjdk.java.net/jdk/pull/8606
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v6]
On Tue, 10 May 2022 06:52:00 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has updated the pull request incrementally with one additional commit > since the last revision: > > update copyright header src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2022, Oracle and/or its affiliates. All rights > reserved. Remove "2019, ", same with other classes. The header (along with the LastModified tag) serves as an indication that you've modified the file. As this is the first of such modification, it just needs to be noted with the year it's done, that is "2022, ". - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v5]
On Mon, 9 May 2022 07:00:34 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has refreshed the contents of this pull request, and previous commits > have been removed. The incremental views will show differences compared to > the previous content of the PR. The pull request contains one new commit > since the last revision: > > Add last modified tag After the last update, the years in the copyright header and LastModified tag do not match. For example, the header for XPATHErrorResources_de.java starts like: Copyright (c) 2019, 2021, where 2021 needs to be updated to 2022. When I mentioned using XPATHErrorResources_ja.java as an example, I meant replacing "reserved comment block" with the copyright header and then update the copyright year. Sorry if I wasn't clear enough. But basically using that as a template for the format of the header, and keep the year updated to the current. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v3]
On Fri, 6 May 2022 14:33:50 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has updated the pull request incrementally with one additional commit > since the last revision: > > Replace the ER_RTF_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER key in > XPATHErrorResources language files Changing resource bundles is not required as the L10n resource files update would cover that. As you've modified the files, you'll need to update the license header, using XPATHErrorResources_ja.java as an example and update the year and LastModified tag. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8286154: Fix 3rd party notices in test files
On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato wrote: > Trivial fix to 3rd party copyright notices. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8558
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v2]
On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has updated the pull request incrementally with one additional commit > since the last revision: > > Updating last modified tag and XRTreeFragSelectWrapper.java Note that I've run the tests locally. The default test configuration is tier1, which isn't really helpful in this case excepting heating up the planet. If you plan to do more on java.xml, you may run tier2 to verify your changes. - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v2]
On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has updated the pull request incrementally with one additional commit > since the last revision: > > Updating last modified tag and XRTreeFragSelectWrapper.java Looks good. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java
On Wed, 20 Apr 2022 15:37:13 GMT, Shruthi wrote:
> Removing the Duplicate keys present in XSLTErrorResources.java and
> XPATHErrorResources.java
>
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java
line 598:
> 596:"rtf() not supported by XRTreeFragSelectWrapper"},
> 597:
> 598: { ER_ASNODEITERATOR_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER,
Please replace the usage in XRTreeFragSelectWrapper, and also update the
LastModified tag.
-
PR: https://git.openjdk.java.net/jdk/pull/8318
Integrated: 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException
On Wed, 20 Apr 2022 20:08:01 GMT, Joe Wang wrote: > Patch note: > > A previous patch had a bug that missed the boundary check, that will cause > StringIndexOutOfBoundsException to be thrown instead of > XPathExpressionException as expected. > > Fix: the fix is to check the boundaries of the parameter "index". > Objects.checkIndex is removed as it's redundant. This pull request has now been integrated. Changeset: 994f2e92 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/994f2e9271355bebf355279d0208c1d2054bab27 Stats: 86 lines in 2 files changed: 82 ins; 2 del; 2 mod 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException Reviewed-by: naoto, lancea - PR: https://git.openjdk.java.net/jdk/pull/8323
Re: RFR: 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException [v2]
> Patch note: > > A previous patch had a bug that missed the boundary check, that will cause > StringIndexOutOfBoundsException to be thrown instead of > XPathExpressionException as expected. > > Fix: the fix is to check the boundaries of the parameter "index". > Objects.checkIndex is removed as it's redundant. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: add the test - Changes: - all: https://git.openjdk.java.net/jdk/pull/8323/files - new: https://git.openjdk.java.net/jdk/pull/8323/files/4205ea6f..17b8c3e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8323=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8323=00-01 Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8323/head:pull/8323 PR: https://git.openjdk.java.net/jdk/pull/8323
RFR: 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException
Patch note: A previous patch had a bug that missed the boundary check, that will cause StringIndexOutOfBoundsException to be thrown instead of XPathExpressionException as expected. Fix: the fix is to check the boundaries of the parameter "index". Objects.checkIndex is removed as it's redundant. - Commit messages: - 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException Changes: https://git.openjdk.java.net/jdk/pull/8323/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8323=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284548 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8323/head:pull/8323 PR: https://git.openjdk.java.net/jdk/pull/8323
Integrated: 8284920: Incorrect Token type causes XPath expression to return incorrect results
On Wed, 20 Apr 2022 17:40:24 GMT, Joe Wang wrote: > Patch note: > > The previous patch changed all literal tokens to use constants. However, > replacing "." with Token.DOT introduced this bug. > While tokens with a single char are inherently of type char, due to the > different implementation of the overloaded method "tokenIs" that takes String > or char, a wrong input type will produce incorrect result. It may be worth it > to take a closer look at the overloaded method, but for now, a quick fix is > to reverse the input type back to String (DOT_STR). > > Test: the issue affect the processing of the short form of the parent axis > "..". The test verifies that all form of the parent axis shall return the > same result. > > Test: all XML tests passed. This pull request has now been integrated. Changeset: 81a8e2f8 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/81a8e2f8b32ad27aed45c4f6966e8d9ecf8b0fc9 Stats: 124 lines in 3 files changed: 122 ins; 0 del; 2 mod 8284920: Incorrect Token type causes XPath expression to return incorrect results Reviewed-by: naoto, lancea - PR: https://git.openjdk.java.net/jdk/pull/8321
Re: RFR: 8284920: Incorrect Token type causes XPath expression to return incorrect results [v2]
> Patch note: > > The previous patch changed all literal tokens to use constants. However, > replacing "." with Token.DOT introduced this bug. > While tokens with a single char are inherently of type char, due to the > different implementation of the overloaded method "tokenIs" that takes String > or char, a wrong input type will produce incorrect result. It may be worth it > to take a closer look at the overloaded method, but for now, a quick fix is > to reverse the input type back to String (DOT_STR). > > Test: the issue affect the processing of the short form of the parent axis > "..". The test verifies that all form of the parent axis shall return the > same result. > > Test: all XML tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: add test cases for the self axis - Changes: - all: https://git.openjdk.java.net/jdk/pull/8321/files - new: https://git.openjdk.java.net/jdk/pull/8321/files/cb5e5ec3..3b61789e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8321=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8321=00-01 Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8321/head:pull/8321 PR: https://git.openjdk.java.net/jdk/pull/8321
RFR: 8284920: Incorrect Token type causes XPath expression to return incorrect results
Patch note: The previous patch changed all literal tokens to use constants. However, replacing "." with Token.DOT introduced this bug. While tokens with a single char are inherently of type char, due to the different implementation of the overloaded method "tokenIs" that takes String or char, a wrong input type will produce incorrect result. It may be worth it to take a closer look at the overloaded method, but for now, a quick fix is to reverse the input type back to String (DOT_STR). Test: the issue affect the processing of the short form of the parent axis "..". The test verifies that all form of the parent axis shall return the same result. Test: all XML tests passed. - Commit messages: - 8284920: Incorrect Token type causes XPath expression to return incorrect results Changes: https://git.openjdk.java.net/jdk/pull/8321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8321=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284920 Stats: 113 lines in 3 files changed: 111 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8321/head:pull/8321 PR: https://git.openjdk.java.net/jdk/pull/8321
Re: RFR: 8186958: Need method to create pre-sized HashMap [v20]
On Thu, 14 Apr 2022 18:05:48 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java >> line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights >>> reserved. >>> 3: */ >> >> The LastModified tag was missing in this class. Pls use this opportunity to >> add it in the same format as the other classes (CoreDocumentImpl, >> XSAttributeChecker), that is after line 52. Thanks. > > @JoeWang-Java done. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v21]
On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > add `@LastModified: Apr 2022` to DocumentCache Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v20]
On Thu, 14 Apr 2022 17:05:39 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > revert changes on ProcessEnvironment src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3: > 1: /* > 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights > reserved. > 3: */ The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Thu, 14 Apr 2022 01:13:18 GMT, XenoAmess wrote:
>> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
>> line 1819:
>>
>>> 1817: Map items;
>>> 1818: LargeContainer(int size) {
>>> 1819: items = HashMap.newHashMap(size*2+1);
>>
>> I'm wondering if we should change this to just `newHashMap(size)` since it
>> looks like this container is intended to hold up to `size` items.
>> @JoeWang-Java ? I suspect the `size*2+1` was a failed attempt at allocating
>> a HashMap of the correct capacity for `size` mappings.
>
>> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the
>> correct capacity for `size` mappings.
>
> I looked the codes and don't think so..
> If I'm wrong, I'm glad to fix.
Stuart's right, I looked at the code, it's as you said a failed attempt, "size"
would be good. So HashMap.newHashMap(size) would actually be a small
improvement.
It's an interesting impl the way it used HashMap, but it's 20 year code.
-
PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Thu, 14 Apr 2022 01:15:05 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java >> line 171: >> >>> 169: _current = 0; >>> 170: _size = size; >>> 171: _references = HashMap.newHashMap(_size); >> >> Not `_size+2` ? > >> Not `_size+2` ? > > I don't have a idea here why he original use the + 2. > Is there any guy more familiar with this code tell me why? > Thanks! size, not size + 2, same situation as size*2+1 below. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v16]
On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer Looks good for the changes in java.xml, like Naoto, assuming copyright years and the LastModified tag are updated. I generally prefer for the source level to stay at 8 as the upstream source is maintained at an older JDK level, but these changes seem to be small enough to tolerate. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v5]
On Tue, 12 Apr 2022 20:33:53 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 11 additional commits since > the last revision: > > - abstract class -> top level interface > - interface -> abstract class > - Merge branch 'master' into JDK-8279185 > - Removed the method > - Merge branch 'master' into JDK-8279185 > - Changed to use a type to determine ISO based or not > - Renamed the new method > - Merge branch 'master' into JDK-8279185 > - Addresses review comments > - copyright year fix > - ... and 1 more: > https://git.openjdk.java.net/jdk/compare/30616d77...7f596789 Looks good to me. For the name, another option might be IsoCompatible instead of IsoBased as historically those other calendars were established before the ISO standard, although technically, in the Java language, it could be said the xChronology is ISO based. - PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v5]
On Tue, 12 Apr 2022 20:33:53 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 11 additional commits since > the last revision: > > - abstract class -> top level interface > - interface -> abstract class > - Merge branch 'master' into JDK-8279185 > - Removed the method > - Merge branch 'master' into JDK-8279185 > - Changed to use a type to determine ISO based or not > - Renamed the new method > - Merge branch 'master' into JDK-8279185 > - Addresses review comments > - copyright year fix > - ... and 1 more: > https://git.openjdk.java.net/jdk/compare/c751c9bd...7f596789 Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8265315: Support for CLDR version 41 [v2]
On Fri, 8 Apr 2022 20:17:52 GMT, Naoto Sato wrote: >> This is to upgrade the CLDR data from version 39 to version 41 which was >> released yesterday. The vast majority of the changes are basically replacing >> the CLDR data, along with tools/testcase alignments. Here is the link to >> CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41 > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 22 commits: > > - Merge branch 'master' into cldr+ > - Merge branch 'master' into cldr+ > - CLDR v41 final > - CLDR v41 beta2 > - Merge branch 'master' into cldr+ > - CLDR v41 alpha4 > - Merge branch 'master' into cldr+ > - Update copyright year to 2022 > - CLDR release v40 > - Merge branch 'master' into cldr > - ... and 12 more: > https://git.openjdk.java.net/jdk/compare/a8c87526...9ef22a6d Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8150
Integrated: 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes
On Tue, 5 Apr 2022 23:05:47 GMT, Joe Wang wrote: > Clean up the usages of isAssignableFrom in a few xpath and jdk/internal > classes where the checks were really about equality or whether they were the > exact class types. It was why they worked nonetheless even though some of > them were backwards. > > Test: existing tests passed. This pull request has now been integrated. Changeset: 0a026759 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/0a0267590fad6a2d14d499588c97bb11e554feb9 Stats: 26 lines in 6 files changed: 1 ins; 0 del; 25 mod 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes Reviewed-by: naoto, lancea - PR: https://git.openjdk.java.net/jdk/pull/8116
Re: RFR: 8265315: Support for CLDR version 41
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR > v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41 Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8150
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato wrote:
>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>>
>>> 61: Locale.of("it", "IT", "EURO"),
>>> 62: Locale.forLanguageTag("de-AT"),
>>> 63: Locale.forLanguageTag("fr-CH"),
>>
>> Use the new factory? Ok not to change as these are tests and there are too
>> many of them. It's not deprecated anyways.
>
> `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it
> validates the input language tag, while `Locale.of()` doesn't as well as
> Locale constructors.
Ok, I didn't realize the existing method is preferred over the new method in
creating a Locale. The javadoc does state that it does not make any syntactic
checks. That's good to know.
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors > (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are > simple replacements to Locale constructors with `Locale.of()` or Locale > constants, such as `Locale.US`. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato wrote:
>> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>>
>>> 79:
>>> 80: /**
>>> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>>
>> Locale.France?
>
> The test code parses the input string (eg. "fr_FR") into 3 elements, `name`,
> `country`, and `variant`, then create a `Locale` using those 3 elements.
> Changing it to `Locale.FRANCE` does not seem right here.
I see.
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `Locale.US`.
test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 61: Locale.of("it", "IT", "EURO"),
> 62: Locale.forLanguageTag("de-AT"),
> 63: Locale.forLanguageTag("fr-CH"),
Use the new factory? Ok not to change as these are tests and there are too many
of them. It's not deprecated anyways.
test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 56: check(mf1, mf2, false);
> 57:
> 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
Locale.JAPAN?
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `Locale.US`.
test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131:
> 129:
> 130: // Tests with the Japanese imperial calendar
> 131: Locale calendarLocale = Locale.of("ja", "JP", "JP");
Locale.JAPAN?
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `Locale.US`.
test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 79:
> 80: /**
> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
Locale.France?
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes [v2]
On Wed, 6 Apr 2022 15:54:30 GMT, Naoto Sato wrote: > Looks good to me. This would have been a premiere example for switch pattern > match, but hey. Yeah, totally understand the urge to use new features. - PR: https://git.openjdk.java.net/jdk/pull/8116
Re: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes [v2]
On Tue, 5 Apr 2022 23:55:22 GMT, Naoto Sato wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> replace with instanceof
>
> src/java.xml/share/classes/jdk/xml/internal/JdkXmlFeatures.java line 326:
>
>> 324: public void setFeature(int index, State state, Object value) {
>> 325: boolean temp;
>> 326: if (Boolean.class.isInstance(value)) {
>
> Could this be `value instanceof Boolean`?
Looks like instanceof is preferable in this case. Replaced.
-
PR: https://git.openjdk.java.net/jdk/pull/8116
Re: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes [v2]
> Clean up the usages of isAssignableFrom in a few xpath and jdk/internal > classes where the checks were really about equality or whether they were the > exact class types. It was why they worked nonetheless even though some of > them were backwards. > > Test: existing tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: replace with instanceof - Changes: - all: https://git.openjdk.java.net/jdk/pull/8116/files - new: https://git.openjdk.java.net/jdk/pull/8116/files/84a9dceb..5d6a6e3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8116=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8116=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8116/head:pull/8116 PR: https://git.openjdk.java.net/jdk/pull/8116
RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes
Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards. Test: existing tests passed. - Commit messages: - 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes Changes: https://git.openjdk.java.net/jdk/pull/8116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8116=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279876 Stats: 26 lines in 6 files changed: 1 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8116/head:pull/8116 PR: https://git.openjdk.java.net/jdk/pull/8116
Re: RFR: 8283994: Make Xerces DatatypeException stackless
On Wed, 30 Mar 2022 11:38:59 GMT, Aleksey Shipilev wrote: > See bug report for more details. This change improves > SPECjvm2008:xml.validation for about +3%: > > > baseline: 298.353 ± 1.008 ops/min > patched: 309.912 ± 1.347 ops/min > > Of course, the real improvements might be even higher, as exception might be > thrown from much deeper call hierarchy. > > Additional testing: > - [x] Linux x86_64 fastdebug, `jaxp_all` > - [x] Linux x86_64 fastdebug, `javax/xml` Marked as reviewed by joehw (Reviewer). src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java line 2: > 1: /* > 2: * Copyright (c) 2017, 2022, Oracle and/or its affiliates. All rights > reserved. Update the LastModified tag below as well. Otherwise, looks good. - PR: https://git.openjdk.java.net/jdk/pull/8036
Re: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables [v2]
On Tue, 29 Mar 2022 21:41:52 GMT, Naoto Sato wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove variable, check instance instead. > > src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java line 44: > >> 42: >> 43: //Indicates whether this is the Catalog instance (vs a Catalog entry) >> 44: boolean isCatalogInstance = false; > > Can we eliminate this instance variable, by checking whether the type is > `Catalog` or not in `resetOnStart()`? Yes, thanks! - PR: https://git.openjdk.java.net/jdk/pull/8018
Re: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables [v2]
> Resets state of a Catalog instance on each matching call so that it can be > reused. Adjusts CatalogResolver's resolve routine so that it continues to > observes the PREFER feature in a resolution process. Without the adjustment, > PreferFeatureTest would fail. > > Mach5 XML tests passed: > https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove variable, check instance instead. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8018/files - new: https://git.openjdk.java.net/jdk/pull/8018/files/14513d7b..16bebbcf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8018=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8018=00-01 Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8018/head:pull/8018 PR: https://git.openjdk.java.net/jdk/pull/8018
Re: RFR: 8283889: Fix typo in package-info.java
On Tue, 29 Mar 2022 18:23:31 GMT, Lance Andersen wrote: > Hi all, > > Please review this trivial fix which addresses a typo in > src/java.sql/share/classes/java/sql/package-info.java > > make docs is clean and I am also running mach5 tier1 as an extra sanity check > so there are no surprises when the patch is pushed > > Best > Lance Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8020
RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables
Resets state of a Catalog instance on each matching call so that it can be reused. Adjusts CatalogResolver's resolve routine so that it continues to observes the PREFER feature in a resolution process. Without the adjustment, PreferFeatureTest would fail. Mach5 XML tests passed: https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 - Commit messages: - 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables Changes: https://git.openjdk.java.net/jdk/pull/8018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8018=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253569 Stats: 220 lines in 5 files changed: 198 ins; 18 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8018/head:pull/8018 PR: https://git.openjdk.java.net/jdk/pull/8018
Integrated: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char
On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between > the parser and serializer. The parser rejected control characters while the > serializer converted them to NCRs. The fix is for the later to be aligned > with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. This pull request has now been integrated. Changeset: f4fd53d0 Author:Joe Wang URL: https://git.openjdk.java.net/jdk/commit/f4fd53d0aee67319bf2c7bcaa671c2e97e66383f Stats: 197 lines in 4 files changed: 182 ins; 3 del; 12 mod 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char Reviewed-by: lancea, naoto - PR: https://git.openjdk.java.net/jdk/pull/7945
Re: RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char
On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between > the parser and serializer. The parser rejected control characters while the > serializer converted them to NCRs. The fix is for the later to be aligned > with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. For XML 1.0, it's known that they were invalid. For prefs, it would be nice to add InvalidPreferencesFormatException to exportSubtree to match with that of importPreferences. But it's such an edge case, for this patch, I opted for no signature change. - PR: https://git.openjdk.java.net/jdk/pull/7945
RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char
The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. Mach5 tier2 passed. - Commit messages: - 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char Changes: https://git.openjdk.java.net/jdk/pull/7945/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7945=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273370 Stats: 197 lines in 4 files changed: 182 ins; 3 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7945.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7945/head:pull/7945 PR: https://git.openjdk.java.net/jdk/pull/7945
Re: RFR: 8283277: ISO 4217 Amendment 171 Update
On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE > redenomination (removing 3 zeros). Its effective date is 4/1, but I went > ahead as JDK19 won't be released by 4/1. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7857
Re: RFR: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value [v2]
On Fri, 11 Mar 2022 22:20:38 GMT, Naoto Sato wrote: >> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary >> decimal/grouping separator symbols. Fix is straightforward to use the >> correct symbols depending on the formatter type. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Refined the test Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7790
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For the bundles in java.xml: For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date. For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header. In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well. - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v4]
On Mon, 7 Mar 2022 18:20:43 GMT, Naoto Sato wrote:
>> Supporting `IsoFields` temporal fields in chronologies that are similar to
>> ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull request contains five additional commits since
> the last revision:
>
> - Renamed the new method
> - Merge branch 'master' into JDK-8279185
> - Addresses review comments
> - copyright year fix
> - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate
src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689:
> 687: */
> 688: @Override
> 689: public boolean isIsoBased() {
Is this meant to be 'default'? The CSR indicated adding default methods.
-
PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8281093: Violating Attribute-Value Normalization in the XML specification 1.0
On Mon, 7 Mar 2022 17:07:20 GMT, Ravi Reddy wrote: > This fix is for violation of XML specification on Attribute-Value > normalization for external entities having character "\r". > > While normalizing entity with '\r', we should be checking if the entity is > external before changing the position and offset. "isExternal()" check is > missed in the new method : > normalizeNewlines(short version, XMLString buffer, boolean append,boolean > storeWS, NameType nt). > . Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7731
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
On Mon, 7 Mar 2022 03:00:45 GMT, Roger Riggs wrote: >> OK, I propose `isIsoBased()` for the name, which I initially thought of. If >> there is no objection, I will modify the spec/impl. > > Is `IsoBased` is fine with me. "isISOLike" is too vague. That matches the javadoc as well, that it "supports ISO based fields". - PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v2]
On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to >> ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > copyright year fix Is the public API change, adding the isIsoLike() method, necessary? It seems to me we already have the isSupported method for that purpose and plus isSupportedBy from the IsoFields. Would making sure the IsoFields are supported at the implementation level be sufficient? - PR: https://git.openjdk.java.net/jdk/pull/7683
Integrated: 8282583: Update BCEL md to include the copyright notice
On Thu, 3 Mar 2022 17:51:31 GMT, Joe Wang wrote: > Update BCEL md to include the copyright notice. This pull request has now been integrated. Changeset: 8478173d Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/8478173d837113bf603aadb614badd461f474250 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod 8282583: Update BCEL md to include the copyright notice Reviewed-by: lancea, iris, naoto - PR: https://git.openjdk.java.net/jdk/pull/7681
Re: RFR: 8282583: Update BCEL md to include the copyright notice [v2]
> Update BCEL md to include the copyright notice. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove the section that's no longer in the notice file - Changes: - all: https://git.openjdk.java.net/jdk/pull/7681/files - new: https://git.openjdk.java.net/jdk/pull/7681/files/be8b704c..0e025466 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7681=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7681=00-01 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7681.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7681/head:pull/7681 PR: https://git.openjdk.java.net/jdk/pull/7681
Re: RFR: 8282583: Update BCEL md to include the copyright notice
On Thu, 3 Mar 2022 18:36:32 GMT, Lance Andersen wrote: > > Yes, it's 2020. The latest release, 6.5.0, was released in 2020. The text > > comes from the NOTICE.txt file in the BCEL 6.5.0 release. > > Thank you for the confirmation Joe! Thanks Lance, and Iris! - PR: https://git.openjdk.java.net/jdk/pull/7681
Re: RFR: 8282583: Update BCEL md to include the copyright notice
On Thu, 3 Mar 2022 17:51:31 GMT, Joe Wang wrote: > Update BCEL md to include the copyright notice. Yes, it's 2020. The latest release, 6.5.0, was released in 2020. The text comes from the NOTICE.txt file in the BCEL 6.5.0 release. - PR: https://git.openjdk.java.net/jdk/pull/7681
RFR: 8282583: Update BCEL md to include the copyright notice
Update BCEL md to include the copyright notice. - Commit messages: - 8282583: Update BCEL md to include the copyright notice Changes: https://git.openjdk.java.net/jdk/pull/7681/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7681=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282583 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7681.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7681/head:pull/7681 PR: https://git.openjdk.java.net/jdk/pull/7681
Re: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F
On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although > it is an incompatible change, I believe it is worth the fix. For that, a CSR > has been drafted. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7640
Re: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F
On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although > it is an incompatible change, I believe it is worth the fix. For that, a CSR > has been drafted. Was the following assessment in the bug report correct? "the symbol F in java.time.DateTimeFormatter is no use in any pattern. It just may cause an exception." If true, then it seems the compatibility risk would be low since pattern letter "F" as is currently defined is of no use. Also, the CSR summary needs to be a summary of the action to be taken, that is, changing the pattern definition. The current statement is similar to the problem statement. - PR: https://git.openjdk.java.net/jdk/pull/7640
Re: RFR: 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0
On Fri, 25 Feb 2022 00:50:49 GMT, Ravi Reddy wrote: > While normalizing entity with '\r' , we should be checking if the entity is > external before changing the position and offset. Please also update the @LastModified to "Feb 2022" - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7617
Re: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2]
On Tue, 15 Feb 2022 22:31:28 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/CompactNumberFormat.java line 595: >> >>> 593: divisor = (Long) divisors.get(++compactDataIndex); >>> 594: iPart = getIntegerPart(number, divisor); >>> 595: } >> >> This and the few lines surrounding it were duplicated. Might be worth >> considering consolidation. > > Right. In fact, I tried to converge them but ended up not to, as there are > slight differences for each number type. Yeah, that's fine. - PR: https://git.openjdk.java.net/jdk/pull/7412
Re: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2]
On Tue, 15 Feb 2022 22:31:47 GMT, Naoto Sato wrote: >> Fixing an issue in `CompactNumberFormat` which was caused by >> BigDecimal.divide() that incremented the number in the resulting format >> string. Also fixing some typos by taking this opportunity. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Addressing review comments Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7412
Re: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range
On Wed, 9 Feb 2022 22:37:45 GMT, Naoto Sato wrote:
> Fixing an issue in `CompactNumberFormat` which was caused by
> BigDecimal.divide() that incremented the number in the resulting format
> string. Also fixing some typos by taking this opportunity.
Marked as reviewed by joehw (Reviewer).
test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java
line 106:
> 104: {COMPACT_PATTERN8, List.of(new
> BigInteger("223565686837667632"), new BigDecimal("12322456774334.89766"),
> 3, 3456.78,
> 105: new BigInteger(""), new
> BigDecimal(".0"), 999_999),
> 106: List.of("223566T", "12T", "30K", "3K", "1T", "1T",
> "1M")},
The case where 999_999_999 was formatted to 1000 million and now 1 billion may
be added too.
-
PR: https://git.openjdk.java.net/jdk/pull/7412
Re: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range
On Wed, 9 Feb 2022 22:37:45 GMT, Naoto Sato wrote: > Fixing an issue in `CompactNumberFormat` which was caused by > BigDecimal.divide() that incremented the number in the resulting format > string. Also fixing some typos by taking this opportunity. src/java.base/share/classes/java/text/CompactNumberFormat.java line 595: > 593: divisor = (Long) divisors.get(++compactDataIndex); > 594: iPart = getIntegerPart(number, divisor); > 595: } This and the few lines surrounding it were duplicated. Might be worth considering consolidation. - PR: https://git.openjdk.java.net/jdk/pull/7412
Re: RFR: 8176706: Additional Date-Time Formats [v3]
On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject >> enhancement. CSR has also been updated according to the suggestion. >> >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7340
Re: RFR: 8176706: Additional Date-Time Formats
On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato wrote:
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line
254:
> 252: public static String getLocalizedDateTimePattern(String
> requestedTemplate,
> 253: Chronology chrono,
> Locale locale) {
> 254: Objects.requireNonNull(locale, "requestedTemplate");
Typo, "locale" should have been requestedTemplate.
src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java
line 77:
> 75: LocaleProviderAdapter lpa =
> LocaleProviderAdapter.getResourceBundleBased();
> 76: // CLDR's 'u'/'U' are not supported in the JDK. Replace them with
> 'y' instead
> 77: final var modifiedSkeleton = requestedTemplate.replaceAll("[uU]",
> "y");
Seems to me requestedTemplate needs to be validated when it gets passed to
getLocalizedDateTimePattern, similar as to appendLocalized
-
PR: https://git.openjdk.java.net/jdk/pull/7340
Re: Additional Date-Time Formats
Hi Naoto,
Looks good to me, and thanks for the explanation. I agree, AIOOBE would
be a separate bug with ofPattern.
Thanks,
Joe
On 1/25/22 2:30 PM, Naoto Sato wrote:
Hi Joe,
On 1/24/22 5:50 PM, Joe Wang wrote:
The 2nd and 3rd statements defined the requestedTemplate,
does it imply the characters listed in the snippet are the only ones
that are valid, in other words, can other characters under the
Patterns section be used? It may be helpful to elaborate on the
snippet a bit more.
Those symbols represent each field, so other symbols are considered
illegal as a template symbol. Added some explanation there.
Also, the range implies a valid range for a particular
symbol, if that's the case, y and w feel like they are unbound. If I
do that with ofPettern, I get ArrayIndexOutOfBoundsException.
The spec of 'year' and 'number' presentations do not have any upper
limit number of letters, thus I added the '*' quantifier. Not exactly
sure why AIOOBE is thrown with ofPattern(), could be a separate bug?
It should be zero-padded or sign-padded.
For the sample code, it might be helpful to put them in a code
snippet and with the actual java code. If "yMMM" formats to 'Jun
2020', that might require some explanation too since that would be
the same as ofPattern("MMM y") for the default(US) locale, or was it
a typo?. (I'm not familiar with the use of DTF, just printed out
date.format(DTF.ofPattern("yMMM" and "MMM y") :-))
Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and
`ofPattern("MMM y", Locale.US)` both generating the same result is
exactly what this API is aiming at. Users don't need to pay attention
to locale specific format pattern with this API.
HTH,
Naoto
Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v3]
On Tue, 25 Jan 2022 08:33:21 GMT, Matthias Baesken wrote: >> After 8270492 >> https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 >> has been pushed, we should adjust >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java >> getAbsoluteURI to what has been done in 8270492 to >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Add LastModified Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7155
Re: Additional Date-Time Formats
Hi Naoto,
Nice use of regular expression! Saves a lot of description if I would
just follow the regex pattern.
Question:
The 2nd and 3rd statements defined the requestedTemplate, does
it imply the characters listed in the snippet are the only ones that are
valid, in other words, can other characters under the Patterns section
be used? It may be helpful to elaborate on the snippet a bit more.
Also, the range implies a valid range for a particular symbol,
if that's the case, y and w feel like they are unbound. If I do that
with ofPettern, I get ArrayIndexOutOfBoundsException.
For the sample code, it might be helpful to put them in a code snippet
and with the actual java code. If "yMMM" formats to 'Jun 2020', that
might require some explanation too since that would be the same as
ofPattern("MMM y") for the default(US) locale, or was it a typo?. (I'm
not familiar with the use of DTF, just printed out
date.format(DTF.ofPattern("yMMM" and "MMM y") :-))
Joe
On 1/24/22 4:13 PM, Naoto Sato wrote:
Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by
adding a regular expression for the requested template. This way, it
is less depending on the LDML specification.
Naoto
On 1/21/22 2:39 PM, Naoto Sato wrote:
Thanks, Joe.
Good point. I will elaborate the pattern template part more, less
depending on the LDML spec. Would have been better if we could
introduce our own, such as ofLocalizedPattern(Set
template), but not exactly suffices the need.
Naoto
On 1/20/22 9:52 PM, Joe Wang wrote:
Hi Naoto,
The javadoc points to LDML, it seems to me though it might be useful
to add more information similar to that for the ofPattern methods,
what's under the "Patterns for Formatting and Parsing" section, so
that for at least the common use cases we could rely on the javadoc
without having to consult the LDML specification. Some comparison
with the ofPattern methods might also be helpful.
Just my 2 cents.
Thanks,
Joe
On 1/20/22 1:46 PM, Naoto Sato wrote:
Hello,
I am proposing a couple of new factory methods in
java.time.format.DateTimeFormatter that produce flexible localized
date/time formats, other than the existing pre-defined
(FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a
year and month only string, such as the title for the calendar,
currently they would have to use DateTimeFormatter.ofPattern() with
explicit pattern argument, such as "MMM y". This is problematic
because it is correct in locales such as US, but not correct in
other locales.
So, I propose methods that are parallel to ofPattern(), which take
pattern template. This is based on the CLDR's skeleton:
https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems
Detailed design can be found in the draft CSR:
https://bugs.openjdk.java.net/browse/JDK-8243445
Comments are welcome.
Naoto
Re: Additional Date-Time Formats
Hi Naoto, The javadoc points to LDML, it seems to me though it might be useful to add more information similar to that for the ofPattern methods, what's under the "Patterns for Formatting and Parsing" section, so that for at least the common use cases we could rely on the javadoc without having to consult the LDML specification. Some comparison with the ofPattern methods might also be helpful. Just my 2 cents. Thanks, Joe On 1/20/22 1:46 PM, Naoto Sato wrote: Hello, I am proposing a couple of new factory methods in java.time.format.DateTimeFormatter that produce flexible localized date/time formats, other than the existing pre-defined (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year and month only string, such as the title for the calendar, currently they would have to use DateTimeFormatter.ofPattern() with explicit pattern argument, such as "MMM y". This is problematic because it is correct in locales such as US, but not correct in other locales. So, I propose methods that are parallel to ofPattern(), which take pattern template. This is based on the CLDR's skeleton: https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems Detailed design can be found in the draft CSR: https://bugs.openjdk.java.net/browse/JDK-8243445 Comments are welcome. Naoto
Re: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492
On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java > getAbsoluteURI to what has been done in 8270492 to > src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Thanks Alan for the reminder. The change looks good. Please add a copyright header and the LastModified tag as the other class did. - PR: https://git.openjdk.java.net/jdk/pull/7155
Re: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from > version 13 to version 14. Corresponding CSR has also been drafted. I like how they changed dizzy face to face with crossed-out eyes. Pistol to water pistol, that's even better, just to avoid any confusion ;-) - PR: https://git.openjdk.java.net/jdk/pull/6974
