Explore the changes to the Java baseline, including protections from future changes for Spring in Spring 5.x.
- [Instructor] We're going to go through some of the high-level construct changes within the Spring Framework 5, and one of the first ones that we're going to note is the JDK baseline. With 5.0, there was a Java upgrade so that a minimum version of 1.8 was required. There's also out of the box full support for JDK 9 for both runtime and compilation. Now one thing to note is that longterm support for 1.8 actually ended with Java 11. And as such, you really need to go to 5.1 in order to get support for Java 11.
Also along these lines was that the releases are actually de-coupled from the JDK due to several delays that happened. But full support out of the box for JDK 9 came with Spring 5.0, and then 5.1 as I said, brought 11. Now, with this change you also get API support for Java EE or Jakarta EE for 1.7. And 1.8 API runtime support. Now, a few things that come with that is 1.7 gave us Servlet 3.1, Bean Validation 1.1, JPA 2.1, and JMS 2.0.
With 1.8, we get Servlet 4.0, Bean Validation 2.0, JPA 2.2 and JSON binding API 1.0. So Jakarta EE is really the way to go with 1.8 as you're moving forward. Now as I mentioned previously, with 5.1 we get full Java upgrades to JDK 11. And JDK 11 is the new LTS supported version of Java, from Oracle. We also get support for GraalVM, with its native image constraints on things like reflection and parameter names.
We also get Reactor Core 3.2 support out of the box with 5.1, which becomes very powerful in this non-blocking model. Now this is the age-old question within software development, how should you respond? So Java support is critical, especially if you're writing web applications. And 1.8 LTS has been replaced with 11. As such you really should be moving to JDK 11, unless you're with open JDK that has promised some level of support for 1.8.
Now out of the box, no other versions will be supported because 9 was deprecated with 10, and 10 becomes deprecated with 11. So if you're going to stick with Oracle you're going to need to move up to 11 to stay in support. And with security bugs and performance issues that happen all the time in Java, I'd never would recommend staying on a deprecated version. Now there are a few warnings that I'm going to bring with this. And this is just from experience. And if you've ever written Java or ever managed systems, these are going to be a no brainer.
JDK upgrades can be painful. And with these changes, from 9, 10, 11 we need to be very, very careful where we're using reflection and mocking frameworks. A lot of the changes have not been updated in those libraries that are required to move fully into these new modern JDKs. And I will state this again as well from experience. The JDK upgrade is actually probably going to be significantly harder than the Spring upgrade itself.
So if you've been staying modern on your JDKs, this will be less of a concern than if you've haven't stayed modern. If you're still running 1.7, you may experience some pretty significant hurt moving to this new model. But the JDK baselines were expected with the changes that Oracle made and Spring is kept up to date with JDK changes.
- Spring core changes
- Spring web changes
- Spring test changes
- Spring Boot changes