RFR: 7113349 JDK8 port to macosx
michael.x.mcmahon at oracle.com
Tue Mar 6 03:02:36 PST 2012
On 05/03/12 23:29, Stuart Marks wrote:
> On 3/5/12 12:52 PM, Stephen Bannasch wrote:
>> At 4:05 PM +0000 3/5/12, Michael McMahon wrote:
>>> I'm still having problems reproducing this, even with the same boot
>>> JDK you are using.
>> I've reproduced John's error on 10.6.8 applying webrev.4 on top of
>> The error occurs running ./test_gamma:
>> echo "Doing vm.make build:"
>> Doing vm.make build:
>> All done.
>> cd bsd_amd64_compiler2/product&& ./test_gamma
>> Using java runtime at:
>> Error occurred during initialization of VM
>> at java.util.Hashtable.put(Hashtable.java:432)
>> at java.lang.System.initProperties(Native Method)
>> at java.lang.System.initializeSystemClass(System.java:1115)
> OK, I think I figured it out. It's our old friend LANG.
> Earlier in this thread, John had observed
>> The NPE is because libjava.dylib is handing a null value to
>> Hashtable, for the key "user.language", in System.c.
> The user.language property comes from (or at least is related to) the
> LANG environment variable. If LANG is unset, I get this crash in
> test_gamma. If LANG is set to en_US.UTF-8 the build succeeds.
> Curiously, with LANG=en_US.UTF-8, the build log says
> WARNING: LANG has been set to en_US.UTF-8, this can cause build
> Try setting LANG to 'C'.
> but the build succeeds. There is no corresponding warning if LANG is
> unset. :-(
> Also curiously, the jdk7u build on Mac doesn't have the same
> sensitivity to the absence of LANG. I'll try this out on other platforms.
> I'm not sure, but it could be that this problem is unrelated to
> Michael's changes. If so, then sorry for the noise. But at least we
> might have gotten a lead on some other build mysteries.
Great. That's good to know. From what I can see, the reason why 7u does
not show the
same symptom is because test_gamma bails out in the 7u build because it
the file/directory structure of the Apple (boot) JDK. So, it doesn't
actually run the test.
Since 8 is using an openjdk 7 bootstrap, it does know where to find the
files and it runs
the test. The main Java launcher is able to deal with LANG not being
set. It sets
user.language to a reasonable default. But, it appears like gamma
doesn't do that
(and hence the null key for Hashtable.put()).
So, for the moment, I think we just have to ensure that LANG is set. I know
the recommended value is "C", but it does work for the en_XX.UTF-8 locales.
As was pointed out recently, there are other locales where it definitely
(due to dependencies in the build on the output of the date command iirc).
More information about the macosx-port-dev