4

I am confused when it comes to the supported java-versions of spring 4.3.20. Updating a Spring 4.3.20 project to Java 11 worked without any hiccups what so ever. All my tests work fine, the webapp starts up and all the features of Spring that require bytecode-magic like @Cacheable work. How is this even possible? From what I understand I should have to update to Spring 5+. I checked the language level in my maven settings and bytecode version of the generated .class-files and they indeed use major version: 55.

What am I missing?

I build with Java 11 and launch my local tomcat with Java 11. I double checked all my settings and used visualvm to verify that tomcat indeed runs with Java 11.

Heres the output of javap:

enter image description here

roookeee
  • 1,710
  • 13
  • 24

3 Answers3

4

Spring 5.1 supports Java 11, earlier versions do not. See Spring Framework Versions:

JDK Version Range

  • Spring Framework 5.1.x: JDK 8-12
  • Spring Framework 5.0.x: JDK 8-10
  • Spring Framework 4.3.x: JDK 6-8

and What's New in Spring Framework 5.x:

What's New in Version 5.1

General Core Revision

  • Infrastructure:
    • Warning-free support for JDK 11 on the classpath and the module path.

That 4.3.x works on Java 11 might just mean that you have been lucky up to now (not using things that are not compatible with Java 11). Also, Java is pretty good in backwards compatibility, even with the things removed or intentional backwards incompatible changes since Java 9, it is entirely possible that the real broken things in Spring are very small and obscure.

That said, I would not use a set of libraries as vast as Spring with Java 11 if the authors say that Java compatibility is only guaranteed in a later version than you use. If you want to use Spring with Java 11, upgrade to Spring 5.1.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
2

Remember: tests can only prove the presence of bugs, not their absence.

According to some comments on their release blog, 4.3.20 is in deed "not compatible" with Java 11.

On the other hand: spring is a huge framework. So the simple answer might be: it works for, as long as you don't run into areas that will not work.

And keep in mind: any JDK of version N can run bytecode for bytecode that has older versions N-x.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • 1
    But spring uses cglib extensively (when classes do not implement interfaces, which is the case for me) to implement `@Cacheable`, `@Transactional` and the likes. As cglib cannot understand java 11 bytecode in that spring version the application shouldn't start at all. In regards to your comment about tests: yes, but as I said, everything including startup, db-connections, caching etc works fine without any issues. – roookeee Feb 18 '19 at 08:38
  • 1
    @naze Have you checked the byte code version in spring itself? That bytecode might very well be pre Java 11! – GhostCat Feb 18 '19 at 08:42
  • As I already said in my original answer: Yes I did. I attached an image of `javap`'s output. – roookeee Feb 18 '19 at 09:35
  • 2
    @naze That is not the point. Of course a JDK 11 contains JDK 11 class files. The question is whether spring 4.3.20 comes as JDK 11 bytecode (probably not). – GhostCat Feb 18 '19 at 09:45
1

Seems the compatibility is a common question in the community, so there is an answer (kinda) in Spring documentation: https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8

Basically, Spring codebase itself does not use even the features of Java 7, therefore it is compatible with 6.

As to the bytecode transformation, I believe JVM keeps some level of compatibility due to its specs allowing some of the framework's features to work.

However, if the official docs say it is not compatible, then you should rely on this accident, since other features may not work or get broken with patches and minor releases.

P.S. You also mentioned cglib which can be used to manipulate bytecode, but it's not actually required. It does generate Java code or even bytecode that is always backward-compatible in new JVM releases.

Nestor Sokil
  • 2,162
  • 12
  • 28