Developing Graal now requires JDK 8

[Alan Bateman]

On 29/01/2017 20:13, Doug Simon wrote:
>> On 26 Jan 2017, at 23:06, Alan Bateman <alan.bateman at oracle.com> wrote:
>>
>> On 26/01/2017 19:57, Doug Simon wrote:
>>
>>> Hi jigsaw experts,
>>>
>>> As detailed in https://bugs.openjdk.java.net/browse/JDK-8171448, we are now in the unfortunate position of being forced to use a JDK 8 in the ongoing development of Graal. In particular, given the fine grained way we compose the jdk.vm.compiler module[1] (i.e., we don’t compile all its sources in one javac compilation) we now need to compile Graal (sources and tests) with javac from JDK 8. Using javac from JDK 9 always picks up the jdk.vm.compiler classes in the JDK instead of the newer version of the classes. It may be a naive suggestion, but what we’d really like is support for module exclusion (e.g., --exclude-modules=jdk.vm.compiler).
>>>
>>> To help me understand if there’s an existing solution I’m missing, can someone please tell me how a change in some java.base API would be developed. For example, suppose that this method is added to String:
>>>
>>>      String truncate(int trailingCharsToChop) { ... }
>>>
>>> How would other code in the java.base module be compiled against the new API? By virtue of being compiled along with the new String source file?
>>>
>>> What about compiling code in other modules (or tests) that wants to use the new method? That is, how does one convince javac to see the new API?
>> This should do it:
>>
>> javac -Xmodule:java.base -d patch String.java
>>
>> // compile module against the patched java.base
>> javac --patch-module java.base=patch …
> But --patch-module doesn’t allow you to replace module-info.class.
Right, but that is not a concern for the String.truncate example. 
Patching was never intended to replace the module declaration, it is 
instead the approximate equivalent of -Xbootclasspath/p to override 
classes. When patching a module then the module declaration can be 
augmented with --add-reads and --add-exports at either compile or run time.


>   Consider separate javac compilations, A and B where A compiles the core Graal packages and B compiles subsequent Graal packages that depend on the packages in compilation A. Since the jdk.vm.compiler module-info.class in the JDK does not publicly export the packages in A, compilation B will fail with access violations. Even if --patch-module could replace module-info.class, the way we compile the packages in Graal means we’d need to synthesize intermediate versions of module-info.class, representing the packages currently available on the argument to --patch-module. All this reenforces my feeling that one simply cannot compose a module from separate javac compilations when that module is already in the JDK and visible to javac. Hence the need for an option like --exclude-modules.
I think the separate compilation just means there is series of 
complicated commands but ultimately you are looking to build and run 
with a completely different version of jdk.vm.compiler.

All I can suggest is that we look again at making jdk.vm.compiler an 
upgradeable module and part of that would be working through whatever 
issues there are with the separate compilation.

-Alan