On 2014-09-16 23:03, Naoto Sato wrote:
I revised the fix based on suggestions from Erik/Magnus. I just ended
up creating Gensrc-jdk.localedata.gmk, instead of renaming
GensrcCLDR.gmk because GensrcLocaleData.gmk (formerly
GensrcLocaleDataMetaInfo.gmk) is also needed to build jdk.localedata:
On 2014-09-17 11:36, Erik Joelsson wrote:
On 2014-09-16 23:03, Naoto Sato wrote:
I revised the fix based on suggestions from Erik/Magnus. I just ended
up creating Gensrc-jdk.localedata.gmk, instead of renaming
GensrcCLDR.gmk because GensrcLocaleData.gmk (formerly
Hello Naoto,
From what I can see, this means that GensrcCLDR.gmk now only generates
source for the jdk.localedata module. This means that
Gensrc-java.base.gmk should no longer include GensrcCLDR.gmk and
GensrcCLDR.gmk should be renamed to Gensrc-jdk.localedata.gmk.
/Erik
On 2014-09-16
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 that
Gensrc-java.base.gmk should no longer include GensrcCLDR.gmk and
GensrcCLDR.gmk should be renamed to
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
At one point you mention that CLDR 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
Yes, the current plan is to make the CLDR's data the default one, only
when it is available. Requiring it in the java.base would be problematic
for smaller environments. This will be addressed in 8008577.
Naoto
On 9/16/14, 9:50 AM, Mandy Chung wrote:
At one point you mention that CLDR will
I revised the fix based on suggestions from Erik/Magnus. I just ended up
creating Gensrc-jdk.localedata.gmk, instead of renaming GensrcCLDR.gmk
because GensrcLocaleData.gmk (formerly GensrcLocaleDataMetaInfo.gmk) is
also needed to build jdk.localedata:
On 9/16/14 9:57 AM, Naoto Sato wrote:
Yes, the current plan is to make the CLDR's data the default one, only
when it is available. Requiring it in the java.base would be
problematic for smaller environments. This will be addressed in 8008577.
Do you mean the EN cldr data is big?
Mandy
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
It's okay then and 8008577 will address this properly. This revised
webrev looks okay to me.
http://cr.openjdk.java.net/~naoto/8058509/webrev.1/
Mandy
On 9/16/14 2:39 PM, Naoto Sato wrote:
No. But I suppose smaller environments would just need JRE's locale
data only. Including even some
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 9/15/2014 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 the LocaleDataMetaInfo of CLDR from
14 matches
Mail list logo
