that packaging changes that relate to Jigsaw module system
aren't included in this changeset.
Naoto Sato and Masayoshi Okutsu
with
all the filename or
directory changes. But I hate to hold up your integration plans.
I'd like to get some advice from Erik on this before saying anything further.
-kto
On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote:
Hello,
Please review the JDK8 changes for JEP 127: Improve Locale Data
, and I will go ahead and merge them to my changeset.
Naoto
Other than that, I have no objections to the review.
/Erik
I'd like to get some advice from Erik on this before saying anything
further.
-kto
On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote:
Hello,
Please review the JDK8 changes
review:
http://cr.openjdk.java.net/~naoto/6336885/webrev.01/
This includes:
- a couple of fixes to the CLDR Converter
- Added fallback for any bad SPI implementations which return null for
requested instances.
Still asking for review comments.
Naoto
On 8/8/12 2:13 PM, Naoto Sato wrote:
On 8
it would be good to also add some space
between those changes and these ones - if that is feasible.
This isn't my call, I'm just airing concerns :)
Thanks,
David
On 14/08/2012 7:43 AM, Naoto Sato wrote:
Since I haven't heard any more comments from Erik/Kelly, I would like to
push the changeset
to get the
patch completed before I had to run. (webrev and mercurial wouldn't
cooperate). I will get it done asap today.
/Erik
On 2012-08-13 23:43, Naoto Sato wrote:
Since I haven't heard any more comments from Erik/Kelly, I would like
to push the changeset without the new build infra patch. Erik
identification
7168528 LocaleServiceProvider needs to be aware of Locale extensions
7171372 (cal) locale's default Calendar should be created if unknown
calendar is specified
Please note that packaging changes that relate to Jigsaw module
system
aren't included in this changeset.
Naoto Sato and Masayoshi
Hi Michael,
Looks like the list does not reflect the recent changes introduced by
the re-organization of the locale data (sun/util/resources).
To me, just keeping an eye on the files sounds error prone. Would it be
possible to add some automated check, say in jcheck?
Naoto
On 9/10/12 2:26
Hello,
I need someone to review my changes to the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231
The fix is to move locale data out of rt.jar into localedata.jar which
will be optional in the compact profile
(http://openjdk.java.net/jeps/161) The gist of the
Thank you for the review, Alan.
On 10/31/12 3:06 AM, Alan Bateman wrote:
I looked through the changes and they look fine to me, it's good to have
this separation. Also good to see that you've also updated the makefiles
for the new build system. If we were continuing with the old build
system
My bad. This should have been fixed with 8001231. Looks good to me.
Naoto
On 11/8/12 8:40 AM, Erik Joelsson wrote:
Small fix for class file diff that was introduced with the changes to
locales.
http://cr.openjdk.java.net/~erikj/8003177/webrev.01/
Here are my comments:
- Bundle.java
Line 277,297: Do we need two separate iteration loops here? Two
iteration loops look like the same.
Line 303: typo paris
Line 606: typo Someting
Line 728: Could use foreach here.
- CLDRConverter.java
Line 388: The FormatData bundle is now OPEN, which
Thank you, Okutsu-san. It looks good to me now.
Naoto
On 12/7/12 8:05 AM, Masayoshi Okutsu wrote:
Thank you for your review comments.
On 12/7/2012 5:49 AM, Naoto Sato wrote:
Here are my comments:
- Bundle.java
Line 277,297: Do we need two separate iteration loops here? Two
iteration loops
Hello,
(To build-dev folks, I am sending this to you as the change includes one
modification in make directory. It is just simply adding a new Java
file, so I think it won't affect the new build-infra structure)
Please review the changes for this issue:
Hello,
Is anyone looking into this issue (on the jbs, noone is assigned)? This
has been biting me as well on Windows builds quite a while.
Naoto
On 4/8/13 7:11 AM, Alexander Scherbatiy wrote:
On 4/8/2013 5:21 PM, Erik Joelsson wrote:
On 2013-04-08 15:17, Anthony Petrov wrote:
Thanks for
Hello,
Please review the fix for the following bug. At the moment, it's not yet
reflected in the bug database, but the symptom is that
sun.util.resources.en package is split between rt.jar and
localedata.jar, which would make it problematic in Jigsaw environment
Hi Alan,
On 09/10/2013 08:44 AM, Alan Bateman wrote:
I've looked through the changes (except the old build) and I don't see
anything obviously wrong. The only question I have is on the footprint,
meaning the number of classes that move from localedata.jar to rt.jar.
Do you happen to know the
Hi Erik,
Is there any reason that those jars *have to* be created in images
build? localedata.jar is also in the same boat, and it's even more
difficult for incremental build, since those locales are loaded as
extensions with ServiceLoader.
Naoto
On 9/12/13 11:54 PM, Erik Joelsson wrote:
On 9/16/13 12:59 AM, Magnus Ihse Bursie wrote:
Our goal was that the default build should give a way to run the java
launcher, and nothing more than this. Compiled jars are not neccessary
for this, since you can run the launcher directly with the classes as-is
on disk.
OK, I wasn't aware of
Hi Magnus,
Well, it would work for Latin languages, but not for others, e.g., CJK.
I thought that the general rule was to run the build in English
environment. I would think that French CL.EXE would produce English
version string on Windows configured for en_US locale.
Naoto
On 10/4/13
a locale. It is not the case with
cl.exe, anyway. And in this case, Microsoft apparently does not provide the
English version to French users. Hence this fix.
/Magnus
4 okt 2013 kl. 18:18 skrev Naoto Sato naoto.s...@oracle.com:
Hi Magnus,
Well, it would work for Latin languages, but not for others
, it is the French version that
runs
Anyhow, I think that for this specific case of VS C++ which is not a
compiler that follows the Linux/Cygwin rules --ie LANG=en_US, one should
provide a way to support non en_US VS C++ compiler for computing the
vervion used.
Francis
Le 04/10/2013 19:16, Naoto Sato
Hi Magnus,
I think we need to make it clear that the locale we support for building
the JDK is US English, which is proven to work, and it should be
documented in README-builds.html or similar. Your change in configure
script looks good, in order for passing non-English CL.EXE through, but
I
Hello,
Please review this fix:
http://cr.openjdk.java.net/~naoto/8027289/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8027289
The fix is to add Chinese locales with explicit scripts (Hans/Hant) in
JRE's locale provider adapter's supported locales if corresponding
implicit Chinese
is to address this latter part.
Naoto
On 2/10/14, 12:23 AM, Masayoshi Okutsu wrote:
I wonder if we can utilize the locale matching mechanism rather than
tweaking the makefile. zh-CN and zh-Hans-CN can be treated as
equivalents for looking up the JRE locales.
Masayoshi
On 2/5/2014 11:54 AM, Naoto Sato
problem.
No. It does not happen with Serbian with the said reason above.
Naoto
Thanks,
Masayoshi
On 2/11/2014 2:00 AM, Naoto Sato wrote:
I thought about it and probably it would make sense to utilize locale
matching mechanism in LocaleProviderAdapter, where it selects the most
preferred
On 8/15/14, 3:13 AM, Erik Joelsson wrote:
* GensrcCLDR.gmk is not ideal. It generates source for multiple
modules, and the output is separated afterwards. Fixing this will
probably means some modification to the java helper tools.
While I think it would be good to split this in principle, I'm
Hello,
Please review the changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8038436
The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
The idea is to introduce an SPI so that supported locales are
dynamically searched at runtime,
Thank you Mandy for a quick review. Please see my comments below.
On 8/22/14, 2:26 PM, Mandy Chung wrote:
On 8/22/14 11:46 AM, Naoto Sato wrote:
http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
I skimmed on the patch and have a few initial comment/questions.
JREENLocaleDataMetaInfo
On 8/22/14, 3:56 PM, Mandy Chung wrote:
A service config file can contain multiple provider implementation
classes. JDI connector is one example:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/74078474d9bd/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector
There may be
.
I'd appreciate it if someone in the build-dev could review the makefile
changes.
Naoto
On 8/22/14, 11:46 AM, Naoto Sato wrote:
Hello,
Please review the changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8038436
The proposed changes are located at:
http
/sun.util.locale.provider.LocaleDataMetaInfo
src/jdk.localedata/share/classes/sun/util/locale/provider/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo
-
src/jdk.localedata/META-INF/localedata-services/sun.util.locale.provider.LocaleDataMetaInfo
Mandy
On 8/28/14 11:34 AM, Naoto Sato wrote
as to the build script/makefile, but on second thought it's
less evil than possible future regressions.
Please review:
http://cr.openjdk.java.net/~naoto/8038436/webrev.5/
Naoto
On 8/28/14, 11:34 AM, Naoto Sato wrote:
Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
changes
On 8/30/14, 5:47 AM, Alan Bateman wrote:
On 29/08/2014 22:07, Naoto Sato wrote:
I incorporated the suggestions from Mandy and Alan. Also one change
since the last webrev was to revert the hard-coding of the supported
locales list back to the one which dynamically generates the lists
providers' supported
locales, as they will be in maintenance mode.
Otherwise, the fix looks good to me.
Thank you for the review!
Naoto
Thanks,
Masayoshi
On 8/30/2014 6:07 AM, Naoto Sato wrote:
I incorporated the suggestions from Mandy and Alan. Also one change
since the last webrev
On 9/2/14, 11:48 AM, Mandy Chung wrote:
GensrcCLDR.gmk and GensrcLocaleDataMetaInfo.gmk generate sources for
java.base and jdk.localedata. I think we should re-examine to modify
the tool e.g. to take an input parameter specifying which locales or
module the source is generated for. This will
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net/~naoto/8058509/webrev.0/
The fix is intended to move the LocaleDataMetaInfo of CLDR from
java.base module to jdk.localedata module,
CLDR's data is accessible only when cldrdata.jar is available, including
their en resources. There is no need to put their en resources in
java.base.
Naoto
On 9/15/14, 6:11 PM, Mandy Chung wrote:
On 9/15/2014 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue
Thanks, Erik and Magnus. Will take a look and revise the fix.
Naoto
On 9/16/14, 2:49 AM, Magnus Ihse Bursie wrote:
On 2014-09-16 09:41, Erik Joelsson wrote:
Hello Naoto,
From what I can see, this means that GensrcCLDR.gmk now only generates
source for the jdk.localedata module. This means
will become the default in JDK 9.
Would you need to move them back to java.base when it becomes the default?
Mandy
On 9/16/14 9:30 AM, Naoto Sato wrote:
CLDR's data is accessible only when cldrdata.jar is available,
including their en resources. There is no need to put their en
resources in java.base
/8058509/webrev.1/
Please review.
Naoto
On 9/15/14, 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net/~naoto/8058509/webrev.0/
The fix is intended to move
No. But I suppose smaller environments would just need JRE's locale data
only. Including even some portion of CLDR locale data in java.base would
make it not possible for them to jrecreate the image without CLDR.
Naoto
On 9/16/14, 2:09 PM, Mandy Chung wrote:
On 9/16/14 9:57 AM, Naoto Sato
Hello,
Please review the proposed changes to the following bug:
https://bugs.openjdk.java.net/browse/JDK-8061382
The webrev is available at:
http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
This is mainly build changes to separate CLDR locale data into a new
module. All those CLDR
, and have a wrapper that adds them automatically instead.
/Erik
On 2014-10-18 00:31, Naoto Sato wrote:
Hello,
Please review the proposed changes to the following bug:
https://bugs.openjdk.java.net/browse/JDK-8061382
The webrev is available at:
http://cr.openjdk.java.net/~naoto/8061382/webrev.00
On 10/20/14, 12:49 AM, Alan Bateman wrote:
Will it eventually be possible to create a runtime that has the CLDR
locale data but does not have the legacy JRE locale data? I'm assuming
the CLDR does not have any dependences on the classes in the JRE locale
data.
Yes, that should be possible in
Thanks for the naming suggestion, Alan. I will use classic then.
I also think we should introduce CLASSIC as a property name for the
java.locale.providers system property which should be an alias to JRE,
this requires a CCC though.
Naoto
On 10/23/14, 6:55 AM, Alan Bateman wrote:
On
/~naoto/8061382/webrev.01/
Naoto
On 10/17/14, 3:31 PM, Naoto Sato wrote:
Hello,
Please review the proposed changes to the following bug:
https://bugs.openjdk.java.net/browse/JDK-8061382
The webrev is available at:
http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
This is mainly build changes
with GENSRC_JDK_LOCALEDATA_CLASSIC?
/Erik
On 2014-10-23 22:05, Naoto Sato wrote:
I revised the fix according to the suggestions I got. The main change
is to rename the name of the locale data modules. Now we have two as
follows:
- jdk.localedata.classic: Legacy locale data
- jdk.localedata.cldr
Thank you, Magnus, Erik for the comments. My comments inline below:
On 10/31/14, 6:32 AM, Erik Joelsson wrote:
On 2014-10-31 14:21, Magnus Ihse Bursie wrote:
1) I do not like how gensrc/Gensrc-jdk.localedata.cldr.gmk is included
in CreateJars.gmk -- it should not be there. The reason is to
Quick question. Why is jdk.localedata module included in the compact
profiles? The data there used to be in lib/ext/localedata.jar and
lib/ext/cldrdata.jar which weren't included in those compact profiles.
Naoto
On 12/4/14, 5:48 AM, Alan Bateman wrote:
On 04/12/2014 12:58, Xerxes Rånby
Hi Chris,
Thank you for reporting this problem. We are aware of this issue and
will be fixed in the next update release.
Naoto
On 12/30/14, 1:16 PM, Chris Metcalf wrote:
Our JDK 1.6 and 1.7 builds began failing today with the message Error:
time is more than 10 years from present:
Hello,
Please review the proposed changes for 8008577[1], the implementation of
the JEP-252[2]. The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8008577/webrev.00/
Here are the very high level summary of changes:
- Now the default locale provider order is CLDR,JRE,SPI.
Thank you for the quick review, Erik!
Naoto
On 6/9/15 12:59 AM, Erik Joelsson wrote:
Hello Naoto,
Build changes look good to me.
/Erik
On 2015-06-08 22:58, Naoto Sato wrote:
Hello,
Please review the proposed changes for 8008577[1], the implementation
of the JEP-252[2]. The proposed
/9/2015 5:58 AM, Naoto Sato wrote:
Hello,
Please review the proposed changes for 8008577[1], the implementation
of the JEP-252[2]. The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8008577/webrev.00/
Here are the very high level summary of changes:
- Now the default locale
is not modified
after its initialization.
Otherwise, the changes look good to me.
Masayoshi
On 6/24/2015 6:56 AM, Naoto Sato wrote:
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8008577/webrev.01/
As to the 3rd comment below, I did not modify it because that would
simply duplicate
+1
Naoto
On 6/30/15 12:49 AM, Erik Joelsson wrote:
Hello,
Please review this small patch which fixes the incremental build of
java.base-gensrc. There is a slight mistake in
jdk/make/gensrc/GensrcCLDR.gmk where the target file of a rule has the
wrong path, so make will always think it needs to
Hello,
Please review the changes for the following issues that are the
regressions for fixing 8008577:
8129881: 8008577 breaks Nashorn test
(https://bugs.openjdk.java.net/browse/JDK-8129881)
8130845: Change to CLDR Locale data in JDK 9 b71 causes SimpleDateFormat
parsing errors
Hi Bob, Alan,
On 10/16/15 8:11 AM, Bob Vandette wrote:
I've skimmed through the patches and the DEF_* macros look okay. The only one
that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then
I think the include of jni_util.h needs to move from jawt.h to jawt.c.
Ok, I’ll
Thanks for the review Tim!
On 7/20/16 5:40 PM, Tim Bell wrote:
Naoto:
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8160873
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8160873/webrev.01/
The gist of the issue is that those
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8160873
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8160873/webrev.01/
The gist of the issue is that those tools used to generate sources at
build time were affected by the
Looks good to me.
Naoto
On 10/20/16 1:33 AM, Masayoshi Okutsu wrote:
Hi,
Please review the changes for JDK-8165804 which is a follow-up of
JDK-8076757. Some notes on the changes.
- Removed INCLUDES := $(TEXT_PKG_LD) from
make/gendata/GendataBreakIterator.gmk in order to avoid compiling
Hi Mandy,
Just noticed that the CLDR license is located under jdk.localedata
module. That needs to be moved into java.base, as its English resource
files are derived from CLDR too.
Naoto
On 12/7/16 1:28 PM, Mandy Chung wrote:
This proposes to organize license files by module in source,
Looks good to me.
Naoto
On 7/19/17 10:33 PM, Nishit Jain wrote:
Hi,
Please review the fix for JDK-8177472
Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
Issue:The existing process of updating the LSR data requires manual
Looks good to me.
Naoto
On 6/14/18 11:52 AM, Erik Joelsson wrote:
Hello,
Here is a new version of the patch:
http://cr.openjdk.java.net/~erikj/8204973/webrev.02/
Changes from last time:
* Made the regexp for finding locales more correct. It still does not
try to match 3 letter language
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
This fix is to remove the hand crafted map file (lib/tzmappings) on
Windows, which maps Windows
Hello,
Please review the changes to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8189784
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8189784/webrev.02/
There were two causes of the issue. One was that j.t.f.ZoneName
contained hard coded mappings
indent [1]. In this case I would also advocate
breaking the line sooner to make side by side comparisons easier in the
future.
/Erik
[1] http://openjdk.java.net/groups/build/doc/code-conventions.html
On 2018-04-09 13:20, Naoto Sato wrote:
Hello,
Please review the changes to the following
Hi,
Please review the fix to the subject issue. While fixing 8189784 [1], I
noticed that not only CLDR zones but also tzdb link entries are also
hard coded. So I further modified j.t.f.ZoneName to generate tzdb
entries at the build time.
The issue:
changeset (it
was actually described as a comment in the jira issue).
Naoto
On 9/12/18 9:08 AM, Erik Joelsson wrote:
On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209880
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
The fix is to remove the use of HashSet/Map which is not guaranteed to
preserve the same order on
Hi Magnus,
I am assuming that the generated resource bundles are exactly the same
as before this fix, correct?
Naoto
On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote:
The CLDR data is, since Jigsaw, used in two different modules --
java.base and jdk.localedata. Unfortunately, the split between
Thanks, Magnus. The change looks good to me too.
Naoto
On 2/5/19 1:57 AM, Magnus Ihse Bursie wrote:
On 2019-02-01 14:43, naoto.s...@oracle.com wrote:
Hi Magnus,
I am assuming that the generated resource bundles are exactly the same
as before this fix, correct?
Yes. I have verified this
As for the wording, I'd suggest "Non-US Locale" instead of
"Non-English." Some tests may depend on US customary behavior, such as
date format, decimal separator, etc.
Naoto
On 4/15/19 6:59 AM, Erik Joelsson wrote:
Hello,
Documenting this is certainly the least we can do. If our tests depend
Adding build-dev, as the change adds a small build tool to parse emoji-data.
Naoto
On 5/22/19 3:26 PM, naoto.s...@oracle.com wrote:
Hi,
Please review the changes to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8221431
The proposed CSR and changeset are located at:
Hi Erik,
Thank you for your comments. Updated the webrev accordingly:
https://cr.openjdk.java.net/~naoto/8221431/webrev.04/
Naoto
On 5/22/19 4:13 PM, Erik Joelsson wrote:
Hello Naoto,
In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double
$$. I would recommend calling the
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
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
Hi Magnus,
Looks good to me. Although I cannot provide any reproducible problematic
instance, there have been instances where native tools, such as `date`
command had produced localized date, and the build failed to parse it in
US format. Anyways, it is a good preventive measure to me.
Looks good.
Naoto
On 4/28/20 2:19 AM, Magnus Ihse Bursie wrote:
For no really good reason, the generatecharacter buildtool outputs the
current time in the generated source. While this has no effect on the
generated class files, it makes gensrc comparison fail between builds.
Bug:
Hi Magnus,
I looked at i18n related changes:
make/CopyInterimTZDB.gmk
make/ToolsJdk.gmk
make/gendata/Gendata-java.base.gmk
make/gendata/GendataBreakIterator.gmk
make/gendata/GendataTZDB.gmk
make/gensrc/GensrcCharacterData.gmk
make/gensrc/GensrcEmojiData.gmk
They look ok to me.
The *.java
On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the patch for tzdata2020b integration into JDK.
>
> Release details can be found here:
>
> https://mm.icann.org/pipermail/tz-announce/2020-October/59.html
>
> Bug:
On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020c to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-October/60.html
> Bug:
+1
Naoto
On 8/25/20 11:47 AM, 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
On Tue, 20 Oct 2020 11:39:36 GMT, Kiran Sidhartha Ravikumar
wrote:
>> Hi Guys,
>>
>> Please review the integration of tzdata2020c to JDK.
>>
>> Details regarding the change can be viewed at -
>> https://mm.icann.org/pipermail/tz-announce/2020-October/60.html
>> Bug:
On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each
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.
This pull request has now been integrated.
Changeset: ae0ca743
Author: Nao
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `character
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:
>
Hi,
Please review the changes to the subject issue. This is to incorporate the
latest language subtag registry definition into the JDK.
-
Commit messages:
- LSR 2020-09-29
- LSR 2020-07-17
Changes: https://git.openjdk.java.net/jdk/pull/1357/files
Webrev:
Hi,
Please review the changes for upgrading the CLDR data to version 38. The vast
majority of the changes are simply the changes in CLDR upstream, and others are
mainly test changes due to the locale data change.
-
Commit messages:
- Updated the version in `cldr.md` files
-
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes for upgrading the CLDR data to version 38. The vast
> majority of the changes are simply the changes in CLDR upstream, and others
> are mainly test changes due to the locale data chan
On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020d to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
> Bug:
On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar
wrote:
>> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
>>
>>> 199: zid.equals("Iran") || // last rule mismatch
>>> 200: zid.equals("Asia/Gaza") || // last rule mismatch
>>> 201:
On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar
wrote:
>> My question is why it is failing. Have you figured it? The existing
>> exceptions are either negative DST or last rule beyond 2037, which javazic
>> cannot handle. The changes introduced with 2020d does not meet either of
On Fri, 30 Oct 2020 10:33:28 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressed the following comments:
>> - https://github.com/openjdk/jdk/
and its spec are in this CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8254629
>
> Naoto
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Addressed the following comments:
- https://github.com/openjdk/jdk/pull/938#disc
and its spec are in this CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8254629
>
> Naoto
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Fixed exception messages.
-
Changes:
- all: https://git.openjdk.ja
Hi,
Please review the changes for the subject issue. This is to enhance the
java.time package to support day periods, such as "in the morning", defined in
CLDR. It will add a new pattern character 'B' and its supporting builder
method. The motivation and its spec are in this CSR:
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.
This pull request has now been integrated.
Changeset: a259ab4a
Author: Naoto Sato
URL:
1 - 100 of 153 matches
Mail list logo
