Compatibility with JDK 9 release candidate [SPR-15686]

[spring-projects-issues]

Juergen Hoeller opened SPR-15686 and commented

A JDK 9 release candidate is supposed to be released on June 22nd: http://openjdk.java.net/projects/jdk9/

---

Affects: 5.0 RC2

Issue Links:

• Upgrade to CGLIB 3.2.5 [SPR-15147] #19713 Upgrade to CGLIB 3.2.5 ("depends on")
• Compatibility with JDK 9 GA [SPR-15992] #18941 Compatibility with JDK 9 GA ("is depended on by")
• Out-of-the-box build compatibility with JDK 9 build 136 [SPR-14645] #19211 Out-of-the-box build compatibility with JDK 9 build 136
• Upgrade to Gradle 4.1 for clean JDK 9 build compatibility [SPR-15667] #20226 Upgrade to Gradle 4.1 for clean JDK 9 build compatibility

[spring-projects-issues]

Juergen Hoeller commented

A first pass has restored basic compatibility with JDK 9 build 175. The only missing piece is an update to AspectJ 1.9 which we'll hopefully get in time for our RC3.

FWIW, it turns out that Gradle 3.5.x is sufficient for our purposes against the JDK 9 RC build 175, so I'm going with the recent Gradle 3.5.1 for the time being.

[spring-projects-issues]

Juergen Hoeller commented

Upgrading to the recent AspectJ 1.9 beta 6, we're once again able to build on JDK 9 proper.

[spring-projects-issues]

Christoph Dreis commented

@jhoeller : Is it planned to have compatibility with JDK 9 in the 4.x release line as well?

[spring-projects-issues]

Juergen Hoeller commented

We're generally compatible with JDK 9 in the 4.3.x line already - in the sense of best-effort support for JDK 9 at runtime, primarily in classpath mode. We backported changes such as #19056 which can cause reflection failures on JDK 9, we've upgraded to CGLIB 3.2.5 (#19713) and Objenesis 2.6 (#20159) there as well, and we tolerate the JDK 9 bytecode level in our ASM 5.2 fork.

However, the 4.3.x framework build cannot run on JDK 9 (#20226), the framework codebase does not avoid JDK 9 deprecations (e.g. #19055), we are not upgrading to ASM 6.0 (#19083), and we won't be shipping any dedicated module names for Jigsaw (#18289; that said, 4.3.x works fine as automatic modules with filename-derived module names). All of those are 5.x only.

[spring-projects-issues]

Christoph Dreis commented

Thanks for the heads up! I'm currently working around one compatibility issue with AspectJ by setting 1.9.0.BETA-6 manually. Could you imagine that - once a stable 1.9.x is out - this could be backported to 4.x?

I also just saw your comment on CGLIB commit cglib/cglib@d6fe1d8 about the unpleasant warnings of defineClass. I guess we have to wait how this turns out.

[spring-projects-issues]

Juergen Hoeller commented

Since AspectJ 1.9 comes with a completely revised Eclipse compiler and no JDK 6 compatibility, we can't upgrade to it in the 4.3.x line by default. That said, we only bring in a specific AspectJ version in spring-aspects; everywhere else, it's optional on our end and therefore a user-declared version of AspectJ in a concrete application project anyway. The 4.3.x line is compatible with AspectJ 1.9 in general, so we can officially support such an opt-in upgrade on an application's side at least.

With respect to CGLIB, this is a somewhat ironic side effect of JDK 9's recent tolerant defaults in classpath mode: Even trying a reflective operation causes the warning, no matter whether a different fallback would be chosen otherwise. As a consequence, ironically, this warning goes away when setting the JVM's illegal-access flag to "deny" (and therefore never appears in module path mode where deny is enforced to begin with), and it also goes away with an explicit open declaration for java.base to ALL-UNNAMED. So it's not a showstopper, just a nuisance... Nevertheless, we might patch our CGLIB fork to avoid the reflective attempt on JDK 9; I have yet to follow up with Rafael there, hopefully sorting this out for our 5.0 RC4 still.

[spring-projects-issues]

Christoph Dreis commented

Sounds reasonable and probably help others to make up their personal roadmap as well. Thanks again!