Compatibility with JDK 9 Jigsaw Builds [SPR-12549]

[spring-projects-issues]

Juergen Hoeller opened SPR-12549 and commented

The Jigsaw branch recently got merged into the JDK 9 mainline snapshots: a good opportunity to do some tests against b42 or higher (https://jdk9.java.net/download/), making sure Spring 4.1.4 builds and runs on it as far as possible.

Further Resources

• GRADLE-3256 and DaemonParameters
• "20.1.1. Forked Java processes" section of the Gradle reference manual

---

Affects: 4.1.3

Issue Links:

• General compatibility with JDK 8u40 [SPR-12585] #17186 General compatibility with JDK 8u40
• General compatibility with JDK 8u60 [SPR-13017] #17608 General compatibility with JDK 8u60

0 votes, 6 watchers

[spring-projects-issues]

Juergen Hoeller commented

As expected, the core framework does build and run on JDK 9. However, the usual suspects in the wider build - the spring-aspects module and the spring-oxm module - break since their build setup relies on custom compilers, none of which have been made compatible with JDK 9 yet.

To be revisited for Spring Framework 4.2 - however, we may be stuck on a JDK 8 build for some time to come. AspectJ 1.9 is unlikely to happen before 2016, and Castor / JiBX / XMLBeans might not get updated any time soon. That said, at this point, there is no need for us to build on JDK 9 either.

[spring-projects-issues]

Juergen Hoeller commented

An update against JDK 9 build 52: spring-oxm builds and its tests pass now. However, spring-aspects still doesn't compile due to AspectJ 1.8.5 not being able to find the standard JDK class library on a JDK 9 installation.

Andy Clement, any chance for AspectJ 1.8.x. to 'tolerate' JDK 9 in such a scenario? There is no need for -target 1.9 yet and probably won't be for years to come; all we'd need is the ability to build and run the entire test suite on JDK 9.

Juergen

[spring-projects-issues]

Andy Clement commented

Hey Juergen, it has been vaguely on my radar to look at but I have not yet had a forcing function to do the work. I see I have that now :) I'll take a look when I get a minute.

[spring-projects-issues]

Andy Clement commented

Hmmm. If it were just the weaver that needed smarts for understanding Java9 that would be one thing but it is also the JDT compiler that we depend upon - that complicates things. I'll reach out to the eclipse guys to see if anyone has already started anything on this.

[spring-projects-issues]

Juergen Hoeller commented

Since we don't need support for the 1.9 language level, maybe there's a way to patch the JDT compiler to just find the class libraries? Assuming there are no other incompatibilities, of course...

If it turns out to be too much hassle, we can defer this until early 2016 as well. It would just be nice to run a CI build against JDK 9 from this summer onwards, once JDK 9 enters its API freeze.

[spring-projects-issues]

Andy Clement commented

maybe there's a way to patch the JDT compiler to just find the class libraries?

It is a bit messy due to all the layers of abstraction in JDT. However, I found that they have a BETA_JAVA9 branch of JDT with some preliminary work in it. I grabbed that, found it was a little incomplete and added a bit more code - this got compilation working but the weaver didn't work so I did some extra hacks to get the weaver limping along too. The upshot is that there does exist an AspectJ 1.9.0.BETA-1. This has been published to repo.spring.io but that repo seems to be going slow from a refresh point of view so my gradle build isn't finding it there (I can't see it in the artifactory browser even though I know it is there) so if you use this repository (which is what repo.spring.io is the facade for):

maven { url "http://s3.amazonaws.com/maven.springframework.org/snapshot" }

and this version

1.9.0.BETA-1

you might get a bit further. Let me know how it goes.

[spring-projects-issues]

Juergen Hoeller commented

Andy, you're the man: The Spring Framework master build and tests pass fine with Aspectj 1.9.0.BETA-1. Thanks for that amazingly quick turnaround!

I'm trying to conditionally add it to 4.2, with our build dynamically switching to Aspectj 1.9.0.BETA-1 when executing on JDK 9... or simply always using it, even on JDK 8, but just for our use of ajc and not for the runtime libs as published in our POMs. The latter would be similar to how we dealt with AspectJ 1.8 vs 1.7 at the time when JDK 8 wasn't GA yet.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

In yesterday's efforts, I accidentally ran the spring-oxm tests after previously executing them on JDK 8... That's what made them pass, since with the generated artifacts not present (i.e. a clean build), the compileTestJava phase fails on JDK 9 build 52, like previously.

Nevertheless, with AspectJ 1.9.0.BETA-1 used for the ajc task, a few spring-core tests fine-tuned and spring-oxm tests selectively deactivated, everything passes fine on JDK 9 with a clean build now. To be pushed once the AspectJ beta shows up at repo.spring.io.

Juergen

[spring-projects-issues]

Sam Brannen commented

Juergen Hoeller, have you been executing gradlew clean test against JDK 9?

I ask, because I just installed the following on my Mac:

java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b53)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b53, mixed mode)

And when I execute gradlew clean test, I get the following compiler error:

:spring-core:compileJava
/Users/XXX/source/spring-framework/spring-core/src/main/java/org/springframework/util/CollectionUtils.java:356: error: incompatible types: List<CAP#1> cannot be converted to List<V>
			List<V> values = Collections.unmodifiableList(entry.getValue());
			                                             ^
  where V,K are type-variables:
    V extends Object declared in method <K,V>unmodifiableMultiValueMap(MultiValueMap<? extends K,? extends V>)
    K extends Object declared in method <K,V>unmodifiableMultiValueMap(MultiValueMap<? extends K,? extends V>)
  where CAP#1 is a fresh type-variable:
    CAP#1 extends V from capture of ? extends V
1 error
:spring-core:compileJava FAILED

[spring-projects-issues]

Sam Brannen commented

Made further changes to Gradle build to support JDK 9 in GitHub commit 7bc44a9:

Set Gradle Daemon JVM args compatible with JDK 9

This commit adds the following to gradle.properties in order to execute
the Gradle daemon on JDK 9, since Gradle's DaemonParameters
automatically sets the MaxPermSize JVM argument, which is no longer
supported on JDK 9.

org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m

[spring-projects-issues]

Sam Brannen commented

See also the "DaemonParameters does not support JDK 9 by default" bug in the Gradle Forum.

[spring-projects-issues]

Juergen Hoeller commented

Hmm. a clean test run does pass for me against JDK 9 build 52... including spring-core. Maybe it's a regression in JDK 9 build 53?

BTW, after those Gradle JVM settings changed, the Gradle wrapper seems to fork a new JVM for every run now. Can we avoid that somehow, even with the new settings in place?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Andy Clement, I can still only grab AspectJ 1.9.0.BETA-1 from the Amazon URL, not from anywhere at repo.spring.io. It does show up at http://repo.spring.io/snapshot/org/aspectj/aspectjtools/ but I can't seem to grab it from there... And shouldn't it be in the /milestone category instead of /snapshot?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Sam Brannen, it's indeed a regression with Java 9 build 53! Fails for me on that very same spot as well now...

So much for tracking a moving target, even within the same week :-)

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Collections.unmodifiableMultiValueMap explicitly casts from List<? extends V> to List<V> now, which apparently is necessary as of Java 9 build 53.