Developing Graal now requires JDK 8

Alan Bateman Alan.Bateman at
Mon Jan 30 10:40:01 UTC 2017

On 29/01/2017 20:13, Doug Simon wrote:
>> On 26 Jan 2017, at 23:06, Alan Bateman <alan.bateman at> wrote:
>> On 26/01/2017 19:57, Doug Simon wrote:
>>> Hi jigsaw experts,
>>> As detailed in, 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
>> // 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.


More information about the graal-dev mailing list