Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK

[Peter Levart]

Hi Stuart and Phil and Tim,

Thanks for explanation. This must be it, yes. I'll try upgrading to 
JDK8u25 again (just downgraded to u20) and see if touching sources helps.

Regards, Peter

On 12/06/2014 10:03 PM, Stuart Marks wrote:
> [Adding build-dev to let them know others are seeing this. I'm not on 
> jigsaw-dev though so this might not make it there.]
>
> Hi Peter,
>
> I ran into this myself the other day and had a wrestling match with 
> it. There's a bug in the build system on this:
>
> https://bugs.openjdk.java.net/browse/JDK-8066761
>
> My understanding is that this has to do with timestamps on the 
> checked-out source files vs. the class files in the boot JDK. With 
> 8u20 as boot, all the class files are out of date w.r.t. the source 
> files so everything is rebuilt. With 8u25, some class files might be 
> newer than the source files, if you've been using the same source tree 
> for a long time (as many of us have).
>
> The workaround is to touch all the source files in the jdk repo before 
> doing a clean build:
>
>     $ cd jdk; hg manifest | xargs touch
>
> or do
>
>     $ cd jdk; hg update null; hg update tip
>
> to re-checkout all the files.
>
> The root cause seems to be inadvertent dependency checks against 
> classes in the boot JDK, which cause the build to mix in old class 
> files from the boot JDK. Obviously if you do a fresh build, everything 
> ought to be out of date, regardless of which boot JDK is in use.
>
> s'marks
>
> On 12/6/14 11:20 AM, Peter Levart wrote:
>> Hi,
>>
>> I thought I might inform you that recent checkout of JDK9 (with 
>> modular RT images) fails to build with JDK8u25 as bootstrap JDK. With 
>> JDK8u20 it works correctly. Tried on Linux and Windows. The 
>> configuration on Linux is:
>>
>> Configuration summary:
>> * Debug level:    release
>> * HS debug level: product
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>>
>> Tools summary:
>> * Boot JDK:       java version "1.8.0_25" Java(TM) SE Runtime 
>> Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM 
>> (build 25.25-b02, mixed mode)  (at /home/peter/Apps64/jdk1.8.0)
>> * Toolchain:      gcc (GNU Compiler Collection)
>> * C Compiler:     Version 4.8.3 (at /usr/bin/gcc)
>> * C++ Compiler:   Version 4.8.3 (at /usr/bin/g++)
>>
>> Build performance summary:
>> * Cores to use:   7
>> * Memory limit:   15757 MB
>>
>>
>> Here's the build session:
>>
>> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release 
>> images
>> Building 'linux-x86_64-normal-server-release' (matching 
>> CONF=linux-x86_64-normal-server-release)
>> Building OpenJDK for target 'images' in configuration 
>> 'linux-x86_64-normal-server-release'
>>
>> Compiling 1 files for BUILD_TOOLS_LANGTOOLS
>> Compiling 20 properties into resource bundles for jdk.compiler
>> Compiling 10 properties into resource bundles for jdk.javadoc
>> Compiling 5 properties into resource bundles for jdk.dev
>> Compiling 818 files for BUILD_INTERIM_LANGTOOLS
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> 1 warning
>> 1 warning
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> 1 warning
>> Warning: generation and use of skeletons and static stubs for JRMP
>> is deprecated. Skeletons are unnecessary, and static stubs have
>> been superseded by dynamically generated stubs. Users are
>> encouraged to migrate away from using rmic to generate skeletons and 
>> static
>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>> Creating buildtools/interim_langtools.jar
>> Compiling 198 files for BUILD_INTERIM_RMIC
>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>> Compiling 6 files for BUILD_TOOLS_CORBA
>> Compiling 141 files for BUILD_IDLJ
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: 
>> error: cannot find symbol
>>             LambdaForm form2 = mh.editor().filterArgumentForm(1+i, 
>> BasicType.basicType(newType));
>>                                  ^
>>   symbol:   method editor()
>>   location: variable mh of type BoundMethodHandle
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: 
>> error: cannot find symbol
>>             mh = mh.copyWithExtendL(midType, form2, fn);
>>                    ^
>>   symbol:   method copyWithExtendL(MethodType,LambdaForm,MethodHandle)
>>   location: variable mh of type BoundMethodHandle
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: 
>> error: cannot find symbol
>>                 LambdaForm form2 = 
>> mh.editor().filterReturnForm(BasicType.basicType(newType), false);
>>                                      ^
>>   symbol:   method editor()
>>   location: variable mh of type BoundMethodHandle
>>
>> ...etc...
>>
>>
>> It seems that something changed between JDK8u20 and JDK8u25 regarding 
>> bootclasspath handling of javac as the above errors suggest that JDK9 
>> sources are being compiled against JDK8 classes.
>>
>>
>> Regards, Peter
>>
>>
>