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 ge
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 get the
CLDRVERSION which is defined in that file. I'd like to address that,
either by extracting the CLDRVERSIO
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: CLDR locale data
Revised webrev is loc
Hi Erik,
Yep, that is not needed so I will remove it. Thank you for catching it.
Naoto
On 10/24/14, 12:28 AM, Erik Joelsson wrote:
Hello Naoto,
Just one thing, in Gensrc-java.base.gmk, shouldn't we still just run the
targets in GENSRC_JAVA_BASE and let Gensrc-jdk.localedata.classic.gmk
deal w
Hello Naoto,
Just one thing, in Gensrc-java.base.gmk, shouldn't we still just run the
targets in GENSRC_JAVA_BASE and let Gensrc-jdk.localedata.classic.gmk
deal with GENSRC_JDK_LOCALEDATA_CLASSIC?
/Erik
On 2014-10-23 22:05, Naoto Sato wrote:
I revised the fix according to the suggestions I g
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: CLDR locale data
Revised webrev is located at:
http://cr.openjdk.java.net/~nao
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 23
On 23/10/2014 09:17, Masayoshi Okutsu wrote:
On 10/23/2014 4:58 PM, Alan Bateman wrote:
jdk.localedata.XXX looks right. I wonder if we can find something
better than "jre" for the suffix of the first one. I ask because
linking that into a runtime that isn't the what we know today as the
JRE mi
On 10/23/2014 4:58 PM, Alan Bateman wrote:
jdk.localedata.XXX looks right. I wonder if we can find something
better than "jre" for the suffix of the first one. I ask because
linking that into a runtime that isn't the what we know today as the
JRE might be confusing.
Actually Naoto and I discu
On 22/10/2014 20:52, Naoto Sato wrote:
Hi Mandy,
As I wrote in a separate email, my preference is the following module
names:
jdk.localedata.jre
jdk.localedata.cldr
This way, they both come under "localedata" (btw, they don't provide
Locale, but the data for locale sensitive services such a
+1
On 10/23/2014 4:52 AM, Naoto Sato wrote:
Hi Mandy,
As I wrote in a separate email, my preference is the following module
names:
jdk.localedata.jre
jdk.localedata.cldr
This way, they both come under "localedata" (btw, they don't provide
Locale, but the data for locale sensitive services
Hi Mandy,
As I wrote in a separate email, my preference is the following module names:
jdk.localedata.jre
jdk.localedata.cldr
This way, they both come under "localedata" (btw, they don't provide
Locale, but the data for locale sensitive services such as DateFormat,
so I prefer to keep "locale
On 10/20/2014 5:25 PM, Naoto Sato wrote:
My motive for the question is the naming because the changes mean we
have jdk.localedata and jdk.localedata.cldr, an arrangement that
suggests that the CLDR locale data augments the jdk.localedata module.
It may be that we need to choose more suitable
On 21/10/2014 01:25, Naoto Sato wrote:
I think we can rename the original jdk.localedata to
jdk.localedata.jre solely for the legacy JRE locale data, and create
the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent
the legacy JRE locale data, and newly create jdk.cldrlocaleda
Thanks, forgot about GensrcLocaleData.gmk being used by more than one
module.
/Erik
On 2014-10-21 02:16, Naoto Sato wrote:
Thank you, Erik. Will incorporate your suggestions in the next webrev.
As to inlining GensrcLocaleData.gmk, it is used not only in
jdk.localedata, but also in java.base w
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 th
Thank you, Erik. Will incorporate your suggestions in the next webrev.
As to inlining GensrcLocaleData.gmk, it is used not only in
jdk.localedata, but also in java.base where English locale data is
included. So it cannot be inlined into Gensrc-jdk.localedata.gmk.
Naoto
On 10/20/14, 12:54 AM,
Hello Naoto,
With this split, I would rather see GensrcCLDR.gmk be renamed
Gensrc-jdk.localedata.cldr.gmk and have the "all" targets etc added to
it. Then Gensrc-jdk.localedata.gmk should no longer include it. Ideally
GensrcLocaleData.gmk would be inlined into Gensrc-jdk.localedata.gmk.
Note
On 17/10/2014 23: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/
This is mainly build changes to separate CLDR locale data i
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 source
20 matches
Mail list logo
