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,
Okutsu-san,
Thanks for your quick reply. I looked at the JDK-6380023. I think my
point was slightly different - what I want to do is to create my own
time zone and use it as default JRE's time zone. But, I agree that the
things discussed in the bug are necessary to achieve my goal with
java.u
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
