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
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.
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:
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
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
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
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
, 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
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
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 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,
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
/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
.
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
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
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
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
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
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
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
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
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 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:
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
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
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,
(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:
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
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
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/
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
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
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
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
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
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
, 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
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
that packaging changes that relate to Jigsaw module system
aren't included in this changeset.
Naoto Sato and Masayoshi Okutsu
101 - 153 of 153 matches
Mail list logo
