Fwd: mx: --strict-compliance is now the only supported mode

[Doug Simon]

As a result of the strict compliance change to mx, you now need an ARM JVMCI JDK8 to build Graal.

Given that there is no JVMCI native port for ARM on JDK8, the solution is to create a JVMCI-jars-only JVMCI JDK8 for ARM. That is, take an ARM JDK8 binary (e.g. from http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html), set it as JAVA_HOME and then run `mx build --no-native` in graal-jvmci-8 (https://github.com/graalvm/graal-jvmci-8). This will produce a JDK that is an exact copy of the original with the JVMCI jars overlayed. Running `mx jdkhome` will show you where the copy was made. Obviously this JDK cannot be used to run Graal since all the native JVMCI code is missing but when assigned to the EXTRA_JAVA_HOMES env var, it will allow `mx build` to succeed.

-Doug

> Begin forwarded message:
> 
> From: Doug Simon <doug.simon at oracle.com>
> Subject: Re: mx: --strict-compliance is now the only supported mode
> Date: 1 June 2018 at 18:55:06 CEST
> To: graal-dev <graal-dev at openjdk.java.net>, "hotspot-compiler-dev at openjdk.java.net compiler" <hotspot-compiler-dev at openjdk.java.net>
> 
> Note that the Graal sources in the JDK *do not* need multiple JDKs to be compiled. That is because we flatten[1] versioned sources when updating these sources.
> 
> -Doug
> 
> [1] https://github.com/oracle/graal/blob/master/compiler/mx.compiler/mx_compiler.py#L1256-L1257
> 
>> On 1 Jun 2018, at 16:54, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> Historically, mx has used a non-strict algorithm when deciding which JDK to use for compiling a project with Java compliance N. The motivation was to support using a single JDK for all compilation. For Java code that only uses public JDK API, this was not a problem. However, both Graal and SVM use non-public JDK API which complicates things. To make it possible to use javac from JDK 9 with a `--release 8` option to compile a project that uses JDK 8 internal API (e.g. sun.misc.Unsafe), mx provided skeletons for the API in question (e.g., Unsafe.java) since the `--release` mechanism only provides symbol for public JDK API. However, this approach did not scale as it meant skeletons need to be provided for every internal API used by any mx project. A better approach is to simply enforce a strict JDK matching algorithm. That is, if a project has a Java compliance of 8, then a JDK 8 must be made available (via JAVA_HOME/EXTRA_JAVA_HOMES or --java-home/--extra-java-homes).
>> 
>> Mx has now been changed to enforce this.
>> Prior to this change, a Java compliance could be either exact or open ended:
>> Compliance Value	Compatible JDKs for compilation
>> 8	JDK8
>> 9+	JDK9, JDK10, JDK11, ...
>> 
>> Since a project may use internal API that spans only a fixed set of JDKs, Java compliance now also supports a fixed range:
>> Compliance Value	Compatible JDKs for compilation
>> 8	JDK8
>> 9+	JDK9, JDK10, JDK11, ...
>> 9..10	JDK9, JDK10
>> The lower bound in a fixed range specifies the language level. That is, it will be used as the value for the -source and -target javac options.
>> 
>> One noticeable impact is that the auto-JDK-selection in mx has been moved to a separate utility: select_jdk.py. When mx cannot find a JDK it needs, you will now get an error message such as:
>> 
>> --------------------------------------------------
>> Could not find a JDK
>> The following JDKs are available:
>> /Library/Java/JavaVirtualMachines/graalvm-1.0.0-rc1/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home
>> /Library/Java/JavaVirtualMachines/jdk8u172-b11
>> /Library/Java/JavaVirtualMachines/labsjdk-20180522-073957
>> /Library/Java/JavaVirtualMachines/labsjdk1.8.0_161-jvmci-0.42/Contents/Home
>> /Library/Java/JavaVirtualMachines/labsjdk1.8.0_171-jvmci-0.43/Contents/Home
>> /Library/Java/JavaVirtualMachines/openjdk-10.jdk/Contents/Home
>> Specify one with the --java-home or --extra-java-homes option or with the JAVA_HOME or EXTRA_JAVA_HOMES environment variable.
>> Or run `/Users/dsimon/mx/select_jdk.py -p /Users/dsimon/graal/graal/compiler` to set and persist these variables in /Users/dsimon/graal/graal/compiler/mx.compiler/env.
>> --------------------------------------------------
>> 
>> The last line shows you how to run the select_jdk.py utility to configure your env file.
>> 
>> This utility can also be used to define a `select_jdk` shell function as described here:
>> 
>> https://github.com/graalvm/mx/blob/master/select_jdk.py#L118-L129
>> 
>> Please feel free to reply or open mx issues on GitHub if you run into any problems as a result of this change.
>> 
>> -Doug
>> 
>