Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with JDK 9 release candidate [SPR-15686] #20245

Closed
spring-issuemaster opened this issue Jun 20, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Jun 20, 2017

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:

  • #19713 Upgrade to CGLIB 3.2.5 ("depends on")
  • #18941 Compatibility with JDK 9 GA ("is depended on by")
  • #19211 Out-of-the-box build compatibility with JDK 9 build 136
  • #20226 Upgrade to Gradle 4.1 for clean JDK 9 build compatibility
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 26, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 29, 2017

Juergen Hoeller commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 10, 2017

Christoph Dreis commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 10, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 10, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 10, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 10, 2017

Christoph Dreis commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.