I've searched and couldn't find anything to suggest that Spring 4.0.0 is not fully backward compatible with Spring 3.x.
Is that indeed the case?
You should be safe if you have updated your third-party dependencies and updated any Spring deprecations in your project. Spring Framework project lead Juergen Hoeller writes in the blog Migrating from Spring Framework 3.2 to 4.0.1:
To a large degree, an upgrade from Spring Framework 3.2 (or earlier) to 4.0.1 should be as straightforward as a change of version numbers in your Maven POMs. Note that you may have to upgrade specific third-party dependencies to a recent enough version (e.g. Hibernate 3.6+, Quartz 1.8+, Jackson 1.8+, Tiles 2.2+)
Read the migration guide on GitHub for details.
I've prepared report on API changes for the Spring releases here: http://abi-laboratory.pro/java/tracker/timeline/spring-framework/
The report includes backward binary- (BC) and source-compatibility (SC) analysis results. The BC between 3.2.16 and 4.0.0 is estimated at 90.08% and SC is estimated at 88.70%.
The report is generated by the japi-compliance-checker tool.
...
There are few API they have removed in the new version. You would not have any surprise changes with the new version, there could be slight changes in the API. But, you have to watch the deprecated APIs which will be the candidate for removal in the forthcoming versions.
Look at this document , they have included few backward compatibility changes and removal of the APIs.
The backward compatibility for object-mapper option of the and components has beed removed.
But there is not much changes mentioned in the document.
It should be backward compatible. I recently watched http://oredev.org/2013/wed-fri-conference/spring-4-on-java-8 and recall Juergen Hoeller saying that they designed Spring 4.0 to be easy to upgrade to from 3.2 its around the 47 minute mark in the video.
I take that to mean that there should be no compatibility issues.
Typically any breaking changes or incompatibility would be noted in the documentation. As you can see there is some deprecated code but it looks to be backwards compatible.
Related
I would like to know the difference between RELEASE, SNAPH, and just version number
So, I am working on a project, in which I have to change spring-core dependency version from 5.2.9.RELEASE to 5.3.11
In my maven repository, under org->springframwork->spring-core, I see below
5.2.8.RELEASE
5.2.9.RELEASE
5.3.4
5.3.6
5.3.8
5.3.9
5.3.10
5.3.11
My project builds successfully only with the 5.3.11 version of spring-core. It is ok to release my project to production with non-release version of spring-core?
The Spring Team changed the version scheme of some projects back in April 2020. As documented in this blog from the Spring Team.
So in short the 5.3.x line doesn't have the RELEASE suffix anymore for the final versions, as it was removed.
When upgrading a framework make sure you upgrade all parts of the framework. Not only upgrade spring-core but also all other related Spring Framework modules to the same version, if not this will eventually come back to hunt you with weird issues (memory, performance, transactions, missing methods etc. etc.).
Java 9 is scheduled to be released soon (July 27). Are there any plans to release a Java 9 compliant version of Spring projects that will be modular (Java 9 project Jigsaw)?
Spring 5, the next major version of Spring, won't be modular. However you can use Spring 5 jars/artifacts as automatic modules in your module-info files. See official blogpost and What's new annoucement.
Conserning module-info.java see Declare Spring modules with JDK 9 module metadata issue last commit:
This issue is marked as "General Backlog", indicating that we won't deal with it for 5.1 (otherwise it'd be marked for 5.1 GA still) and probably not in subsequent 5.x releases either (otherwise it'd be marked as "5.x Backlog").
Specifically, we can't ship module-info files quite yet since we'd need stable module names for all of our optional dependencies... and many of those don't declare stable module names at this point (that is, they don't even include an Automatic-Module-Name manifest entry in their jar). Also, we'd need to build the entire framework on JDK 9+ for the compiler to understand the module-info.java format which is not entirely trivial either, even if the framework itself is known to work fine with JDK 9/10/11 at runtime.
All in all, my prediction about module-info files for 5.1 turned out to be too ambitious. Our current focus is on general JDK 11 compatibility (SPR-16391) on the classpath and as automatic modules on the module path, as well as GraalVM compatibility (SPR-16991). The use of jlink requires manual addition of module-info.class files to the framework jars for the time being... which might stay that way for several years still until we ship a JDK 11 baselined Spring Framework 6.0 against a new generation of dependencies.
Update For 11/3/2022
from Juergen Hoeller in #18079
Our strategic alignment with the module system has been in competition with our AOT and GraalVM native image efforts in 6.0, so we unfortunately had no chance to experiment with a build migration to full module descriptors yet. There have been very few requests for it even in the course of this year, so we wonder whether there is much practical value to be uncovered here for the time being anyway. Looking forward, the use of jlink's module-bounded approach for application/framework-level modules might get superseded by runtime images based on GraalVM-style individual reachability analysis in the long run.
That said, OpenJDK's Project Leyden aims to reuse module system concepts and tools for its standardized static image approach, so deeper module system alignment remains part of our long-term technology strategy for the Spring Framework 6.x generation.
Currently our project is using Gradle-1.3 version and we have a plan of upgrading it to Gradle-2.6 version inorder to implement artifactory in it.
Need to know if we upgrade gradle from 1.3 to 2.6 will there be impact to current artifact creation and if there any specific exclusion in Gradle-2.6/higher which were actually part of inclusion in Gradle-1.3 version?
There are some breaking changes between 1.3 and 2.6. To get most of them I would advise you to take a look at the according release notes. Basic functionality that has worked with 1.3 most likely is working in 2.6 as the Gradle Team is quite cautious in introducing breaking changes. You should just try building your project with Gradle 2.6 and compare the outputs. Keep in mind that already Gradle 2.10 is released which offers some quite nice performance improvements for incremental builds in comparison to 2.6.
What are the jar files I need to use spring expression language in my web app?
This web app itself is not based on Spring. I would like to use the 4.0.1 version. Is spring-expression-4.0.1.RELEASE.jar alone enough?
I assume you need the expression and the core jar. Try with expression only and add core if something still is missing.
And you should consider using 4.1 or even 4.2, 4.1 is available and has no higher requirements than 4.0. 4.2 is scheduled to be released in only a few weeks, so you could start with the already available RC2 and go to final very soon.
We have a project where we're using Spring-js. With it comes Spring-dojo and the full dojo package. But in the current version of Spring-js (2.0.9), it's using dojo 1.3. Is there a way to upgrade manually to dojo 1.4? Or even a new Spring-js.jar-file that can be donwloaded that uses dojo 1.4?
Yes. If you are using the ResourceServlet, you can simply drop the new version of Dojo in the top-level directory of your WAR structure. The ResourceServlet always looks there before it looks on the classpath, thus resources in top-level of the WAR take precedence. I would suggest using a full uncompressed source distro of Dojo during development, and then doing a custom build that is tailored to your usage patterns for production.
Beware that we've occasionally seen some minor incompatibilities when upgrading Dojo versions, so be on the lookout for that and report any issues in the Web Flow Jira.
I suspect we'll be upgrading to Dojo 1.4 in the official distribution for the upcoming Spring Web Flow 2.1 release.
Btw., spring webflow 2.0.9 uses dojo 1.2.4 not 1.3 as the release notes tell