Question: Support for Java9+ in JRE emulation?

[niloc132]

While exploring https://groups.google.com/d/topic/google-web-toolkit-contributors/eyBpbrtYgyY/discussion and using newer language features in the JRE, I ran into an issue with the j2cl_library mechanism as it applies to the JRE (via j2cl_mirror_from_gwt). The easiest way to reproduce it is to take a class already in //jre/java somewhere and update it to use a Java9+ feature - my quick testing sample was tweaking java.lang.Class.getSimpleName() to use var instead of String when declaring the local variable canonicalName:

$ bazel build //jre/java:jre
...
ERROR: /home/colin/workspace/j2cl/jre/java/BUILD:38:1: Building jre/java/libjre.jar (1 source jar) failed (Exit 1)
/jre/java/java/lang/Class.java:76: warning: as of release 10, 'var' is a restricted local variable type and cannot be used for type declarations or as the element type of an array
    var canonicalName = getCanonicalName();
        ^
/jre/java/java/lang/Class.java:76: error: cannot find symbol
    var canonicalName = getCanonicalName();
    ^
  symbol:   class var
  location: class Class<T>
  where T is a type-variable:
    T extends Object declared in class Class
Target //jre/java:jre failed to build

From what I can glean, the way to supporting var (by updating to lang level 10 or higher) would be to modify j2cl_mirror_from_gwt's own java_library and add this line:

        javacopts = ["--release=11"],

However, doing this results in nearly every JRE emul file failing with this error:

/jre/java/java/lang/Class.java:14: error: package exists in another module: java.base
package java.lang;
^

I also tried the now-deprecated source/target flags: javacopts = ["-source 10", "-target 10"],

Is there a more correct way to use j2cl_library to build JRE emulation that uses language features beyond Java 8?

[gkdn]

The proper way is to change the JDK version for Bazel which we piggy back on:
build --java_toolchain=@bazel_tools//tools/jdk:toolchain_java11

However for this particular case (JDK 11), we need additional work in boostrapping due to change around Java modules. The good things is, this will work soonish.

[niloc132]

Great, thank you! I am in no rush, just wanted to get the question out there.

[tbroyer]

However for this particular case (JDK 11), we need additional work in boostrapping due to change around Java modules. The good things is, this will work soonish.

Is the problem the bootclasspath = ["//jre/java:libjre_bootclasspath.jar"] in the j2cl_java_toolchain? and is the solution to use --patch-module java.base=…/libjre_bootclasspath.jar or building a jimage for use with --system?
(I suppose f4420bf is a hint that "soonish" actually means soonish? 😉)

[jbellis]

(A year later) is this still planned for "soon" or is there a different workaround?

[jbellis]

Different workaround. Add this to j2cl_library() in BUILD:

    javacopts = [
    	"-source", "11",
	"-target", "11",
    ],

(Thanks to original poster niloc132 for source diving this.)