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 po
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 wro
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
Naot
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:
http://cr.openjdk.java.net/~naoto/8058509
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 be
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
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 tha
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 iss
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 Gensrc-jdk.l
Looks good to me.
Thanks,
Masayoshi
On 9/12/2014 11:42 PM, Aleksej Efimov wrote:
Hello,
Could you, please, approve a backport of tz2014g related changes to
JDK7. The backport is not straight-forward one, there is no generic
time zone names in JDK7 - because of that the tz names changes
slig
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 01:30
On 9/15/2014 5:59 PM, Aleksej Efimov wrote:
Yoshito, I can explain such behavior only by this part of javadoc +
some calculations: Let's select the Asia/Yakutsk (please, refer to
tzdb rules in previous e-mail) as an example. The 'setRawOffset'
javadoc [1] says the following: "If an underlying T
12 matches
Mail list logo
