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

[Phil Race]

yep lots of people have reported this/seen this

-phil.

On 12/6/14 1: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
>>
>>
>