RFR(S): JDK-8026964 Building with an IBM J9 boot jdk requires special settings for BOOT_RTJAR

[Magnus Ihse Bursie]

Hi Volker,

This will still not work on msys.

While it would be an improvement to check for OPENJDK_TARGET_OS_ENV = windows.cygwin instead (or similar, I don't have source code access at the moment), this would still leave msys out in the cold. I think it's a bit unfortunate to cause msys to break even further.

I have no easy suggestion on how to fix this in msys however, so an AC_MSG_ERROR for windows.msys might be better than nothing. Then at least the missing implementation becomes visible.

You can push multi-repo fixes with a single bug number. I do that all the time.  

If your stage forest does not have a closed counterpart (which I doubt), then you can push this yourself. An autoconf update will be needed when the stage forest is integrated into a forest which has a closed counterpart, but only then, and that is the work of the person doing the integration.

/Magnus

> 18 nov 2013 kl. 17:34 skrev Volker Simonis <volker.simonis at gmail.com>:
> 
> Hi,
> 
> here's a new version of the webrev:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/8026964.v2/
> 
> I now use '-XshowSettings:properties' as suggested by Kumar, but not
> '-version'. This is because '-XshowSettings' didn't work together with
> '-version' before 7u6 (see "7123582 : (launcher) display the -version
> and -XshowSettings",
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123582).
> 
> I know that the official build README mentions 7u7 as the minimum boot
> JDK but as this change is also about non OpenJDK/Oracle boot JDKs I
> prefer to be conservative here (and actually the few more lines that
> must be parsed by AWK don't really make a difference here).
> 
> I've also did yet another small change for the Windows case: I convert
> the content of sun.boot.class.path to Unix form, but with Windows path
> separators. This is required by the FIXPATH utility which will convert
> it back to the Windows form later on during  the build process.
> 
> And unfortunately this change also requires another tiny change in
> jdk/makefiles/Setup.gmk - and all just to make the Windows build
> happy:( We now have to quote BOOT_RTJAR with double quotes in
> jdk/makefiles/Setup.gmk (as this is already done for the Corba make)
> because it is a path list now and not just a single file:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/8026964.jdk/
> 
> I think we must push the jdk-change first, because it will do no harm
> with the current BOOT_RTJAR settings. Afterwards, we can safely push
> the configure change in the root repository. I'm only not sure if I
> need a new Bug-ID for the JDK change because there have been different
> statements regarding such multi-repo changes in the past.
> 
> And I suppose I can't push these changes myself even to stage, because
> they require the re-generation of the closed auto-generated config
> script. So I need your help...
> 
> Thank you and best regards,
> Volker
> 
> On Fri, Nov 15, 2013 at 6:51 PM, Kumar Srinivasan
> <kumar.x.srinivasan at oracle.com> wrote:
>> 
>> Hi Volker,
>> 
>> One thing I notieced,
>> 
>> BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 .......
>> 
>> I suggest using java -XshowSettings:props -version 2>&1 .........
>> 
>> props,  will narrow down the reporting to only properties section, which is
>> really what you want
>> 
>> -version, will allow the launcher to return a 0 exit value, since
>> -XshowSettings
>> behaves like -showversion ie. another class or option is expected for the
>> launcher
>> to continue.
>> 
>> Kumar
>> 
>> 
>> 
>>> Hi,
>>> 
>>> could you please review the following small webrev:
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/8026964/
>>> 
>>> It not only fixes bug 8026964 on AIX, but is changes the general way
>>> of how to compute BOOT_RTJAR.
>>> 
>>> With the new solution, BOOT_RTJAR is computed right from the system
>>> property 'sun.boot.class.path'. The new solution should be more robust
>>> and more portable as it doesn't depend on the name of the jar file
>>> which contains the boot classes and it also doesn't depend on the fact
>>> that all these classes are located in a single jar file.
>>> 
>>> In order to avoid build warnings, I've taken extra care to remove jar
>>> files and paths from the 'sun.boot.class.path' output which do not
>>> exist (e.g. jfr.jar is not available in an OpenJDK build but appears
>>> in 'sun.boot.class.path' anyway - maybe this is another bug that
>>> should be fixed; also jre/classes appears in 'sun.boot.class.path'
>>> although it is not present in the file system - maybe we should fix
>>> that as well).
>>> 
>>> If we are building on Windows, I convert the content of
>>> 'sun.boot.class.path'  to Unix form to avoid problems with the FIXPATH
>>> utility. Later, during the build, FIXPATH will convert the path list
>>> back to Windows form.
>>> 
>>> I've tested the new Solution on Linux, Windows, Solaris and AIX and
>>> couldn't find any problems.
>>> 
>>> I would like to put this into the ppc-aix-port/stage repository but as
>>> this is a general fix and if you'd like to, it would be also OK if
>>> you'd push it right to the build repository.
>>> 
>>> Thank you and best regards,
>>> Volker
>> 
>>