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 2014-09-15 19:24, Mandy Chung wrote:
I am starting to not to count on most people building images and
inclined to catch any new dependence earlier in the default build
to avoid potential build breakage.
The time for verify-modules is not small and there is potential
performance improvement.
On 2014-09-15 18:43, Volker Simonis wrote:
On Mon, Sep 15, 2014 at 11:49 AM, Erik Joelsson
wrote:
On 2014-09-15 10:26, Erik Helin wrote:
On 2014-09-12 17:17, Erik Joelsson wrote:
Hello Erik,
Looks good to me.
Thanks!
On 2014-09-12 17:17, Erik Joelsson wrote:
Don't forget to also pus
On 2014-09-16 09:50, Erik Helin wrote:
On 2014-09-15 18:43, Volker Simonis wrote:
On Mon, Sep 15, 2014 at 11:49 AM, Erik Joelsson
wrote:
On 2014-09-15 10:26, Erik Helin wrote:
On 2014-09-12 17:17, Erik Joelsson wrote:
Hello Erik,
Looks good to me.
Thanks!
On 2014-09-12 17:17, Erik J
On Tue, Sep 16, 2014 at 9:56 AM, Erik Joelsson wrote:
>
> On 2014-09-16 09:50, Erik Helin wrote:
>>
>> On 2014-09-15 18:43, Volker Simonis wrote:
>>>
>>> On Mon, Sep 15, 2014 at 11:49 AM, Erik Joelsson
>>> wrote:
On 2014-09-15 10:26, Erik Helin wrote:
>
>
> On 2014-09-1
On 2014-09-16 08:44, David Holmes wrote:
Hi Magnus,
This seems okay to me.
Thank you. Since this is a hotspot change, I assume I need a second
reviewer, and that it should be pushed into hs-rt, right?
Just for everyone else's benefit. We can pass LOG=info etc as a
configure arg to set th
Looks good to me.
/Erik
On 2014-09-15 13:16, Magnus Ihse Bursie wrote:
Here is the full review of this fix. I have now applied the same
pattern as I used on linux to aix, bsd and solaris as well.
It turned out that windows was problematic. Due to the big difference
between windows and the un
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
On 2014-09-16 09:56, Erik Joelsson wrote:
Actually, autogen.sh will fail unless you use exactly version 2.69. We
started enforcing this a while back (a year maybe?) to avoid the large
superficial diffs.
Unfortunately, this is not entirely true. :(
We have
AC_PREREQ([2.69])
but this will only
On 2014-09-16 11:48, Erik Joelsson wrote:
Looks good to me.
Thank you Erik.
/Magnus
On 16/09/2014 03:04, David Holmes wrote:
At what point, if any, is javac armed with the dependency information
so that it can report any incorrect cross-module references (as we did
for Compact Profiles) ?
That is for further down the road once the module system goes in.
-Alan.
On 16/09/2014 7:37 PM, Magnus Ihse Bursie wrote:
On 2014-09-16 08:44, David Holmes wrote:
Hi Magnus,
This seems okay to me.
Thank you. Since this is a hotspot change, I assume I need a second
reviewer, and that it should be pushed into hs-rt, right?
Right.
Just for everyone else's benefi
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
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
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 be
On 2014-09-16 17:41, Ben Evans wrote:
Hi,
I suspect it'll be easier to just install gcc on your mac. The last time I
checked openjdk 8 didn't compile correctly with clang, so you might also
have to patch the source code as well as the autoconf scripts.
So Apple are now shipping a compiler by d
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
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
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
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
21 matches
Mail list logo
