We have a huge project with a lot of obsolete code and dependencies including spring-core, hibernate, spring-security and a lot more.
Having in mind that we have to migrate this project on JDK 11.
Our first attempt was just to build project with JDK 11. In some cases it worked, but when integration tests were to run, spring(ASM) confused with bytecode. Having read answers on this topic i saw that starting from spring 5 Java 11 is supported. So updating to newest frameworks would be great decision but.. A huge amount of work needs to be done, so much that we cannot even estimate it. My answer is: Have anyone tried running spring 3 on new java versions (8 works fine) or is there an opportunity to do that. Maybe some kind of dependency replacement - to use newer ASM etc or to fork spring and make some changes there? What do you think?
Related
We are currently using spring 3.2.9. We are thinking of upgrading that to a newer version. When I checked the documentation it says that
Along with 4.0 M1, we’ve released Spring Framework 3.2.3, containing
fixes for recently reported issues but also coming with OpenJDK 8 runtime
support. Spring Framework 3.2.x will support deployment on JDK 8 runtimes
for applications compiled against JDK 7 (with -target 1.7) or earlier.
Does that imply that I can't compile on Java 8?
Should I use spring version 4.0.x if I wanna compile with Java 8?
There is a best effort support of JDK8 in the 3.2.x line, as of 3.2.9+.
See SPR-11656 for initial support in 3.2.9 and SPR-11979 for bytecode support improvements in 3.2.10. Please note the support limitations explained in the comments.
For comprehensive support of JDK8, please upgrade to Spring 4.x - there's a dedicated wiki page explaining the upgrade path, and the Spring team made great efforts to make that upgrade experience really easy.
As per my observations, you can actually use spring 3 with code compiled in Java 8, as long as you do not use new java8 syntax in there (like lambdas) in the paths scanned.
So, you can use new APIs (streams ...), but not new syntax (lambdas...).
When I tried, I ended up with startup errors like org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class
Versions of the Spring Framework that are older than 4.0M1 do not work with classes that are compiled for Java 8.
Spring tries to Proxy these classes by reading class files, which won't work if they're "too new". If your #Service classes are compiled with Java 8 as the target, Spring will fail to load the classes on startup.
This means that you will have to upgrade to Spring 4.x.x, if you want to target Java 8 (and use lambdas, default implementations and so on).
I encountered this problem myself a few months ago with a project that uses Spring 3.x.x.
I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.
I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.
What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens' and 'read the documentation here: http://spring.io/' would be very helpful)
The system:
Java 6 - jax-b/-p/-ws/, Apache Commons,
Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi
Hibernate 3.5
Tomcat 6
0 unit tests or automated testing of any kind.
Maven dependency management and build automation.
Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.
Hundreds of views, scores of controllers.
Steps I've taken so far:
Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)
I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.
My questions:
What steps/procedures are considered 'best practice' in these for a job like this?
Does anything jump out at you as a 'gotcha' for a job like this?
Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:
Requirements, requirements, requirements
Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.
If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.
It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.
Spring projects have evolved a lot. Budget for learning time.
This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:
Java 8 features
JavaConfig (as opposed to xml configuration)
Acegi is now Spring Security
Spring projects typically use Spring Boot
Switch from Maven to Gradle for building projects
Full CI using Jenkins (or other CI tools)
Unit and integration testing have moved on to using annotations (and mock frameworks)
Well, it is not easy to answer you question since there are many things to be taken into account.
First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guide that's coming directly from the 'source'.
I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries.
Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts.
Take also a look to the dependency updates section.
Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).
I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.
Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).
It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.
You should also become familiar with Spring 4.x new features and try to exploit them especially those regarding testing improvements.
A little resume of new features is the following:
Removed Deprecated Packages and Methods
Java 8 Support
Java EE 6 and 7 become the baseline
Groovy Bean Definition DSL
Core Container Improvements
General Web Improvements
WebSocket, SockJS, and STOMP Messaging
Testing Improvements with extreme use of annotations
Take also a look to Spring MVC Test Tutorial by Petri Kainulainen that can give you a lot of informations about testing.
You have to have answer to the following before you proceed.
Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?
OR
You really want to get the most out of Spring 4.x ?
Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.
So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.
You may redesign the whole app in Spring 4 as if it is a new application.
Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.
From Migrating from Spring 3 to Spring 4, you would probably get some help from the Spring project's
Spring Integration 3.0 to 4.0 Migration Guide on Github.
Hope it helped!
I need to upgrade the source code for an existing Java EE 1.4 application to Java EE 7. What I need to do primarily? Any particular steps in order which I need to follow?
You are looking into a time difference of 10 years between 1.4 and 7, which in the IT is huge.
Replacing the old J2EE parts by Java EE code basically means rewrite the whole application - so it very much depends on what exactly needs to migrated and how much you can control this scenario.
From an own project where I had to deal with J2EE code I can recommend - if rewriting is not an option - to make the old application run on a new application server and only migrate small parts of it, if possible into a newly deployed application. This worked well, we still have J2EE code in the application and even add/fix small parts in the old code, but it runs together with Java EE code. One thing you have to take care about is the entity manager, because it leads you into trouble if you persist the same data via both ways.
Other than the obvious syntactical changes, I'd suggest looking at what libs you're using and seeing if those are now supported under 7.
When moving application code across versions, most of the time the jump is backwards compatible (I'd say in your case it won't be given such a massive jump) but one of the biggest factors will be if you're using legacy third party code, you'll need to find new supported versions of those products.
This includes say, if you're using a legacy application server and upgrading that. After all this then you can start to consider any syntactical changes that your IDE should help you with :)
I'd recommend WebSphere Migration Toolkit (an Eclipse plugin). Although it's primary usage is to look for a changes, when migrating from other platforms to WebSphere, it will scan your code, jsp pages, xml files and detect any Java, Java EE related issues also. So you will have rough idea what will need to be changed e.g. in relation to JDK changes.
See some info about that toolkit:
WebSphere Migration Toolkit
WebSphere Migration Toolkit download
Other WebSphere migration tools
Last night I was trying to put a simple tutorial to build an application using the stack - Spring (2.5) + JPA (1.0) + Hibernate (downloading for first time, so didn't know which version to use). Unfortunately I didnt want to use Maven as the target participants were on ANT build. As usual hit the search engine and got somehow the steps in the appcontext, persistence.xml and in the java classes. The moment I started getting required libraries, I lost in the JAR hell. Luckily, not much of a problem on the Spring side as all the dependent JARs are packaged together for my Spring 2.5.6.
When it came to hibernate, I had no clue which all Jars to be included on the first place. On the next challenge, didn't know which version for each to add.
Finally I got the whole thing working, but it looks so scary to enter this JAR hell again unless I am taken through Maven heaven.
With lots of interceptors and weaving, it is becoming more complicated for the conventional Java programmer who once liked Java primarily for lots of transparency on what my code is doing.
Am I right in the thought process?
You can still have dependency management while using Ant, use Ivy.
See a detailed tutorial here for more or less exactly the stack you want to use. (Doesn't include Hibernate but I guess you can find how to add that pretty quickly)
And one more thing, if you are referring to the spring.jar which has the full Spring 2.5.6 bundle, I strongly suggest not to use it, you probably need not more than 20% of the libraries included in it. (Take the time to discover exactly which libraries you do need and only pick those.)
Also, consider using Spring 3 if you can, as well as Hibernate, if you are free to pick a version, I'd go for the latest.
I had used other JPA implementations before, but I used Hibernate for the first time this year. Certainly it is more complicated than others in terms of jar dependencies, but in the Getting Started Guide, in Chapter 1, under Obtaining Hibernate I found details on which jars I needed and why.
I did suffer of jar hell problems later on, not because of not knowing which jars to use, but because we are in a really big probject, and other subprojects were already using older versions of Hibernate classes, and this caused me a lot of trouble at runtime and it took me several days to diagnose and fix.
I think this is a reality for the time being, and tools like Maven or frameworks like OSGi attempt to alleviate the problem.
Perhaps the biggest hope we have is Project Jigsaw intended to be part of JDK 8 in the future and which attempts to solve the Java modularity problems we currently have. It will be like a OSGi with steroids, and built in the JDK itself.
But before that happens, all I can tell you is a famous quote by Wiston Churchill
If you are going through hell, keep
going
This is one of the issues that Grails addresses - by bundling a specific set of jars (Spring, Hibernate, etc) that work together and upgrading those jars as Grails evolves.
I last installed Spring a few years ago and back then it was just some jars I had to add. Now after I googled for Spring, it brought me to SpringSource, a division of VMWare.
It took me through a whole installation process for the SpringSource Tool Suite and it looks cool, but is also bulky.
What are people doing for a robust and lightweight Java MVC framework these days?
Well, Spring MVC is a robust and lightweight Java MVC framework these days ;-)
One "problem", though: it uses Spring itself (of course), which has gotten much bigger over the years. What was once just a dependency injection framework, today is almost a complete Java EE replacement. Meaning: if you want Java EE without a true application server, then use Spring. And that boils down to using Tomcat with Spring in most cases.
So, the true answer is: you can still use Spring without much hassle, but use only what you need, if you really need it. Spring originates from 2003, when Java EE was a real pain in the neck, but nowadays Java EE has gotten more and more simple, almost to the point that it's preferred over Spring, especially EE 6.
Springsource Tools isn't needed for using Spring, but it is recommended for efficient Spring usage. If you stick with XML configuration, lack of tools assistance will hamper you in the long run.
My little rant is over, so I hope I helped you at least a bit.
Springsource Tool Suite is their customized distribution of Eclipse, and no you don't technically need it. You still only need the jar files, which can be found here.
You don't need SpringSource Tool Suite.
Spring is still the most popular lightweight Java MVC framework.
Spring is splitted into different modules (projects) to avoid big dependencies if you don't need them.
List of projects from springsource
spring-framework-3.1.0.M1.zip is 25.6 MB and can be found here
Have fun!