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: 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: 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
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: 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: 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: 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
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. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6974
Re: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2]
On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang wrote: >> As a follow up of JEP 411, we will soon disallow security manager by >> default. jtreg 6.1 does not set its own security manager if JDK version is >> >= 18. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > upgrade the version in GHA config > > only in patch2: > unchanged: Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6012
Re: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly.
On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is > that the currency for the country code `XK` is undefined because the country > code is user-defined in the ISO 3166 standard. However, it is commonly used > to represent the region `Kosovo`, which CLDR supports and subsequently is > supported by the JDK since JDK9. Adding the data `EUR` for the country code > `XK` will fix the issue. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5033
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 >> The essential change for this JEP, including the `@Deprecate` annotations >> and spec change. It also update the default value of the >> `java.security.manager` system property to "disallow", and necessary test >> change following this update. >> 2. >> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 >> Manual changes to several files so that the next commit can be generated >> programatically. >> 3. >> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 >> Automatic changes to other source files to avoid javac warnings on >> deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is >> generated programmatically, see the comment below for more details. If you >> are only interested in a portion of the 3rd commit and would like to review >> it as a separate file, please comment here and I'll generate an individual >> webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for >> any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system >> property is now "disallow", most of the tests calling >> `System.setSecurityManager()` need to launched with >> `-Djava.security.manager=allow`. This is covered in a different PR at >> https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, >> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are >> reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: > https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4073
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 > The essential change for this JEP, including the `@Deprecate` annotations > and spec change. It also update the default value of the > `java.security.manager` system property to "disallow", and necessary test > change following this update. > 2. > https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 > Manual changes to several files so that the next commit can be generated > programatically. > 3. > https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 > Automatic changes to other source files to avoid javac warnings on > deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is > generated programmatically, see the comment below for more details. If you > are only interested in a portion of the 3rd commit and would like to review > it as a separate file, please comment here and I'll generate an individual > webrev. > > Due to the size of this PR, no attempt is made to update copyright years for > any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system > property is now "disallow", most of the tests calling > `System.setSecurityManager()` need to launched with > `-Djava.security.manager=allow`. This is covered in a different PR at > https://github.com/openjdk/jdk/pull/4071. java.xml changes look good. Thanks. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073
Re: RFR: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11
On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the > latest language subtag registry definition into the JDK. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3998
Re: RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter
On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato wrote: > Please review the fix to the tier4 build failure. The piece of code that made > into `CLDRLocaleProviderAdapter.java` was also needed in the build tool > counterpart (`CLDRConverter`). Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3553
Re: RFR: 8258794: Support for CLDR version 39
On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote:
> Please review the changes to support CLDR version 39. The vast majority of
> the changes are purely data changes from Unicode. The only change affected in
> logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with
> CLDR's Norwegian language code switch
> (https://unicode-org.atlassian.net/browse/CLDR-2698)
Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-)
Indeed, the majority changes were version and copyright. If you hadn't
mentioned the changed class, it would be almost impossible to find it :-)
-
Marked as reviewed by joehw (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3502
Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian wrote: >> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java >> line 152: >> >>> 150: * >>> 151: * Care must be taken when defining such a filter, as defining >>> 152: * an accept-list too restrictive or a too-wide reject-list may >> >> would "an allow-list too restrictive or a reject-list too wide" read better? > > I agree that there is room for improvement here. How about: > "...an allow-list too restrictively, or a reject-list too broadly, may..." > ? That sounds good to me - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Marked as reviewed by joehw (Reviewer).
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
line 135:
> 133: * The pattern must be in same format as used in
> 134: * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135: * It may define an accept-list of permitted classes, a reject-list
> of
should accept-list be allow-list to be consistent with the other two RMI
classes and ObjectInputFilter.Status#ALLOWED?
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
line 152:
> 150: *
> 151: * Care must be taken when defining such a filter, as defining
> 152: * an accept-list too restrictive or a too-wide reject-list may
would "an allow-list too restrictive or a reject-list too wide" read better?
-
PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29
On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato wrote: > Hi, > > Please review the changes to the subject issue. This is to incorporate the > latest language subtag registry definition into the JDK. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1357
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Hi Erik, We're acting on a report Jon generated separately. The warnings checks are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference). -Joe On 8/25/20 12:39 PM, Erik Joelsson wrote: On 2020-08-25 12:21, Roger Riggs wrote: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. Yes, I get that part, but why are those warnings not triggered today? I don't see any change enabling more warnings from the build. /Erik $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package
Cc-ing build-dev@openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating the checking for warnings in org.w3c is fine. Please be more specific in the comment. "Ignore the doclint warnings in the W3C DOM package" Updated. org/xml/...: If we're suppressing the warnings for org/xml/... then the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. Remove the addition of -Xmaxwarns, it should stay the default. Done. Since its a makefile change, please copy build-dev@openjdk.java.net. Cc-ed The first line comments should terminate with a period ".". javax/xml/stream/FactoryConfigurationError.java:40 javax/xml/stream/XMLStreamException.java:41 javax/xml/xpath/XPathException.java:44 And capitable "Serializable". javax/xml/stream/events/Attribute.java: 50; add "normalized" to the @return line so it is the same as the first line. For simple get methods, the @return mimics the first line. javax/xml/stream/events/NotationDeclaration.java:43 add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks, Roger p.s. There is lots of other cleanup of the javadoc, using @code around true, false, missing periods at the end of first sentences, etc. But that's a different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe On 8/24/20 5:44 PM, Joe Wang wrote: Hi all, adding Roger's comment for the make file to webrev_02 (the only change to webrev_01 is Docs.gmk): http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ Thanks, Joe On 8/21/20 12:49 PM, naoto.s...@oracle.com wrote: +1 Naoto On 8/21/20 12:24 PM, Lance Andersen wrote: Hi Joe, This looks OK. On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: Pelase review a patch to add the missing @return, @throws, @param statements in the java.xml package (excluding the DOM component). JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ Thanks, Joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR(S) : 8238943: switch to jtreg 5.0
+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 version field value being the only difference b/w .00 and .01 Thanks, — Igor On Feb 13, 2020, at 9:23 AM, Erik Joelsson wrote: Looks good, but could you change the "version" field to "5.0", it should work now. /Erik On 2020-02-13 08:50, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8238943/webrev.00 10 lines changed: 1 ins; 0 del; 9 mod; Hi all, could you please review the patch which changes jtreg version used in jdk/jdk to the latest and greatest -- jtreg 5.0? and as (recently became) usually, this patch also bumps requiredVersion in all the jtreg test suites in order to reduce possible discrepancy in results. JBS: https://bugs.openjdk.java.net/browse/JDK-8238943 webrev: http://cr.openjdk.java.net/~iignatyev/8238943/webrev.00 testing: tier1-4 Thanks, -- Igor
Re: [14] RFR: 8212970: TZ database in "vanguard" format support
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". 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 for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 1981 - max)?. I believe it is working as such. The end year is retrieved within the method (line 879) and only the minimum negative saving values within the window is filtered. NegativeDSTTest verifies the tzdata, that is the adjusted data after import, is that correct? I wonder a comment and a bit of details in the test summary would be helpful since there is no negative data in the test itself. Good point. It is confusing. I supplied summary text in the test (also the similar line in TestZoneRules.java) Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ Naoto Best, Joe On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8212970 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ This change aims to support the "vanguard" IANA time zone data format, which uses the negative savings and transition time beyond a day period. The change basically translates those negative savings and transition times, such as 25:00, into the ones that the current JDK recognizes, then produces the data file "tzdb.dat" at the build time. At the run time, the data file is read and interpreted as before. This way the produced tzdb.dat is compatible with the prior JDK releases so that the TZ Updater can also distribute it as a time zone update. I have also refactored redundant copy of ZoneRules file in the build directory, by dynamically importing the file under src. Thus some build related files are modified. I am hoping folks on the build-dev can review those changes. Naoto
Re: [14] RFR: 8212970: TZ database in "vanguard" format support
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 for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 1981 - max)?. NegativeDSTTest verifies the tzdata, that is the adjusted data after import, is that correct? I wonder a comment and a bit of details in the test summary would be helpful since there is no negative data in the test itself. Best, Joe On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8212970 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ This change aims to support the "vanguard" IANA time zone data format, which uses the negative savings and transition time beyond a day period. The change basically translates those negative savings and transition times, such as 25:00, into the ones that the current JDK recognizes, then produces the data file "tzdb.dat" at the build time. At the run time, the data file is read and interpreted as before. This way the produced tzdb.dat is compatible with the prior JDK releases so that the TZ Updater can also distribute it as a time zone update. I have also refactored redundant copy of ZoneRules file in the build directory, by dynamically importing the file under src. Thus some build related files are modified. I am hoping folks on the build-dev can review those changes. Naoto
Re: Fwd: Need reviewer, 7150324: Stop using drop bundles in jaxp
On 3/4/2012 10:12 AM, Kelly O'Hair wrote: Did you see this email?' I didn't. I did not sign up on the build-dev alias until now :) Phil Race reviewed it, but I'd like your review too. I went through the webrev and noted that it's similar to what you did for jdk7 when we worked to remove the drop bundle process for JAXP. The change looks good to me. Thanks, Joe -kto Begin forwarded message: *From: *Kelly O'Hair kelly.oh...@oracle.com mailto:kelly.oh...@oracle.com *Subject: **Need reviewer, 7150324: Stop using drop bundles in jaxp * *Date: *March 2, 2012 12:57:51 PM PST *To: *build-dev build-dev build-dev@openjdk.java.net mailto:build-dev@openjdk.java.net 7150324: Stop using drop bundles in jaxp http://cr.openjdk.java.net/~ohair/openjdk8/infra-jaxp/webrev/ http://cr.openjdk.java.net/%7Eohair/openjdk8/infra-jaxp/webrev/ I'm working on helping to get the jdk8 build-infra changes integrated, this is for jaxp. This is just the changes to the build files to remove the use of the drop bundles and add a new Makefile that won't be used just yet. The ant scripts have been cleaned up and simplified too. The webrevs do not contain the src/ directory addition, made it too big a webrev. I created a make/scripts/update_src.sh script that will copy in the latest source drop bundle that was used for this repository, position it in the src/ directory, and run the whitespace normalizer script. This script could be re-used in the future but it's mostly there to document how I pulled the sources into the repository. Once these changes are reviewed, I would need to: sh ./make/scripts/update_src.sh hg addremove src on the repository before creating the changesets that bring in all these sources. I have run builds and verified that the two deliveries from these repositories (dist/lib/classes.jar and dist/lib/src.zip) match the ones created before this change. The only exception is the whitespace normalization in some of the sources. These changes should not impact the final built jdk bits. -kto
jaxp 1.4.5 and jdk7 integration
Hi Mark, Sure, in the future, I will send updated information about JAXP to the alias. The plan for JDK7-JAXP is to include the following: - all of the P1-P3 bug reports with a few exceptions, - all of the blockers, critical issues, as well as some of the major and minor bug fixes from Apache Xerces 2.10 and Xalan 2.7.1. Some of these have been done through jaxp 1.4.3 and 1.4.4. Other are to be included in JAXP 1.4.5 which will be integrated into jdk7 following the jdk7 milestone schedule http://openjdk.java.net/projects/jdk7/. This is our current plan and may change depending on the jdk 7 requirements. Thanks, Joe On 11/24/2010 11:21 AM, Mark Wielaard wrote: On Wed, 2010-11-24 at 10:50 -0800, Joe Wang wrote: Sorry Mark, and all on build-dev. I didn't pay attention to the build-dev, I mean didn't realize the original email was sent to an outside alias. It's my fault. My notice was ONLY a heads-up for Kelly. I shouldn't have hit reply to all. Please disregard my previous email. I do think these are good things to discuss on the public list. If we want to coordinate on updated jaxp for openjdk7 then we should have that discussion on one of the open lists. So please do post with your ideas and intentions. Thanks, Mark
Re: Need reviewer: jaxp and jaxws urls in openjdk6 and openjdk7
I can confirm the URLs for jaxp are correct. Yes, the file jaxp-1_4_4.zip and jaxp-unittests-1_4_4.zip only exist in the jdk7 download area, so both openjdk6 and openjdk7 refer to that same bundles. By the way, I'm asking around about using download.java.net/jaxp to hold jaxp artifacts in the future. It seems to me that's the same download server as what Kelly pointed out earlier for openjdk, e.g. http://download.java.net/openjdk/jdk7/ --Joe On 11/23/2010 9:33 AM, Joe Darcy wrote: Both sets of changes approved; thanks Kelly. Joe (Wang) and Rama, please verify the new download areas are also populated with the older source bundles so that the earlier builds can be recreated. -Joe Kelly O'Hair wrote: Need reviewer: 7002248: Update urls for jaxp and jaxws source downloads Changes to use the these download areas: https://java.net/downloads/jaxp/jdk7 https://java.net/downloads/jax-ws/JDK7/ https://java.net/downloads/jax-ws/OpenJDK6/ Webrevs: http://cr.openjdk.java.net/~ohair/openjdk6/url-change/webrev/ http://cr.openjdk.java.net/~ohair/openjdk7/url-change/webrev/ The file jaxp-1_4_4.zip only seems to be in the jdk7 download area, so both openjdk6 and openjdk7 refer to that same bundle. -kto
Re: jaxp 1.4.5 - Re: Need reviewer: jaxp and jaxws urls in openjdk6 and openjdk7
It's already in the JDK7 PRD [1]. Also, there is no API changes, just some Apache update and bug fixes required by the exit criteria. [1] http://wiki.se.oracle.com/display/JPG/JDK+7+Engineering+Feature+Plans+Overview --Joe On 11/24/2010 10:13 AM, Kelly O'Hair wrote: Ok. I assume we need some kind of approval to add this to jdk7? Might want to get that ball rolling if it isn't already. Or any CCC request that might be needed. -kto On Nov 24, 2010, at 10:10 AM, Joe Wang wrote: Kelly, By the way, we just finalized a plan on jaxp 1.4.5. We are planning make an internal release first by FF (12/15) of JDK7, to give you so me time to prepare for the integration, we've set 12/8 as the date by which I will provide a source bundle. After that, I will continue working on some bug fixes until 2/2011. The plan is to release jaxp 1.4.5 in 2/2011 and have another integration. A detail link to jaxp 1.4.5 is here: http://wiki.se.oracle.com/display/JPG/JAXP+1.4.5 Thanks, Joe On 11/23/2010 9:20 AM, Kelly O'Hair wrote: Need reviewer: 7002248: Update urls for jaxp and jaxws source downloads Changes to use the these download areas: https://java.net/downloads/jaxp/jdk7 https://java.net/downloads/jax-ws/JDK7/ https://java.net/downloads/jax-ws/OpenJDK6/ Webrevs: http://cr.openjdk.java.net/~ohair/openjdk6/url-change/webrev/ http://cr.openjdk.java.net/~ohair/openjdk7/url-change/webrev/ The file jaxp-1_4_4.zip only seems to be in the jdk7 download area, so both openjdk6 and openjdk7 refer to that same bundle. -kto
please disregard my previous email about jaxp 1.4.5 - Re: jaxp 1.4.5 - Re: Need reviewer: jaxp and jaxws urls in openjdk6 and openjdk7
Sorry Mark, and all on build-dev. I didn't pay attention to the build-dev, I mean didn't realize the original email was sent to an outside alias. It's my fault. My notice was ONLY a heads-up for Kelly. I shouldn't have hit reply to all. Please disregard my previous email. Thanks, Joe On 11/24/2010 10:43 AM, Mark Wielaard wrote: On Wed, 2010-11-24 at d10:20 -0800, Joe Wang wrote: On 11/24/2010 10:13 AM, Kelly O'Hair wrote: On Nov 24, 2010, at 10:10 AM, Joe Wang wrote: By the way, we just finalized a plan on jaxp 1.4.5. We are planning make an internal release first by FF (12/15) of JDK7, to give you so me time to prepare for the integration, we've set 12/8 as the date by which I will provide a source bundle. After that, I will continue working on some bug fixes until 2/2011. The plan is to release jaxp 1.4.5 in 2/2011 and have another integration. A detail link to jaxp 1.4.5 is here: http://wiki.se.oracle.com/display/JPG/JAXP+1.4.5 Ok. I assume we need some kind of approval to add this to jdk7? Might want to get that ball rolling if it isn't already. Or any CCC request that might be needed. It's already in the JDK7 PRD [1]. Also, there is no API changes, just some Apache update and bug fixes required by the exit criteria. [1] http://wiki.se.oracle.com/display/JPG/JDK+7+Engineering+Feature+Plans +Overview There is something wrong with these URLs. Neither of them work. It is as if the wiki.se.oracle.com site doesn't exist. Could this be moved to a public location so we can all discuss it? Thanks, Mark
Re: Need reviewers - 6856630: Restructure jaxp/jaxws repository
Kelly, I'm downloading the JAXP bundle from the kenai test site. It was very slow initially (almost not moving). But it became normal after I killed the 1st attempt. I'm not sure if that's what you meant when you mentioned kenai download was not stable. Maybe it was my internet connection. Did you mean to use kenai instead of the JAXP project site for the JAXP source bundle download? We have a stopper bug after the performance improvement in jdk6u14, which we've just fixed and delivered into u17. We will need to update the JAXP source bundle for JDK7 as well. Please let us know when you're ready for a jprt build. I'll update the source bundle with the fix and some more recent changes. Thanks, Joe Kelly O'Hair wrote: Mark Reinhold wrote: Date: Fri, 11 Sep 2009 16:17:19 -0700 From: kelly.oh...@sun.com Joe Darcy wrote: Generally looks okay; one minor comment, the jaxp webrev has files that appear to be moved as being deleted and added. Yeah, I think that's an artifact of the way I move my patch from one workspace to another. I'll try and fix it when the final changeset is created. hg diff/export --git should do the trick, right? - Mark I thought that's what I used Maybe I forgot to use 'hg mv -A' before I ran diff. -kto
jdk7/jaxp/jaxp: Fixed 6631310 : jaxp issue 42 : dysfunctional hyperlink in package org.xml.sax
Changeset: db868c7da6dc Author:joehw Date: 2007-11-28 22:19 -0800 URL: http://hg.openjdk.java.net/jdk7/jaxp/jaxp/rev/db868c7da6dc Fixed 6631310 : jaxp issue 42 : dysfunctional hyperlink in package org.xml.sax ! src/share/classes/org/xml/sax/ext/package.html ! src/share/classes/org/xml/sax/helpers/package.html ! src/share/classes/org/xml/sax/package.html
