Spring Migration Analyzer: An Assistant For JavaEE To Spring Conversion

Spring's heyday is gone. Nowadays Spring means additional complexity for no benefit.
Instead of migrating from JavaEE to "Spring/Tomcat" better migrate from "Spring/Tomcat" to TomEE, a certidied JavaEE 6 Web Profile application server.
Moreover, the the future of the proprietary Spring products is unclear: www.infoq.com/news/2012/12/vmware-spins-out-spring . Will Spring exist in 3 years?

A great resource for migration in the opposite direction: www.slideshare.net/ertmanb/javaone-2011-migrati... and some real world migration stories: blogs.oracle.com/stories/.

Another great and useful article about the opposite, "Migrating Spring Applications to Java EE 6": howtojboss.com/2012/04/17/article-series-migrat...

TomEE is an option for some but there are many other benefits for migrating to Spring including more flexibility in container choices. Spring is the most popular application framework for enterprise Java for good reasons (see [1] EDC 2011 report or [2] zero turnaround survey 2012). Spring's popularity has never been higher and it continues to inspire Java EE specs because it's moved on to address modern development challenges like NoSQL, Big Data, data, cloud, and intelligent bowser/mobile clients. If you are concerned about the future of Spring you can listen to the [3} panel discussion from JavaOne which discusses very even handedly the future of enterprise Java development.

[1] EDC report www.vmware.com/company/news/releases/vmw-spring...

[2] Zero Turnaround Survey 2012 zeroturnaround.com/labs/developer-productivity-...

[3] JavaOne Panel Discussion oracleus.activeevents.com/connect/sessionDetail...

Just for sake of proper balance, I think the feature adoption argument cuts both ways. There are plenty of things from the Java EE ecosystem that winds up in Spring. It's also the case that Java EE adopts ideas from it's entire ecosystem and not simply Spring (in fact in recent years fewer and fewers ideas have come from Spring as opposed to say the GlassFish, JBoss, Eclipse or Apache ecosystems). In case of Big Data/NoSQL for example, the likely sources of innovation for Java EE are things like Easy-Cassandra, Hibernate OGM or TopLink NoSQL, not Spring Data...

The "container choice" argument is also somewhat artificial. For example, it's long been possible to use Java EE stack technologies on Servlet containers like Tomcat/Jetty, including EJB 3 and CDI...

My motivation for using Spring is that it moves and evolves at a much more rapid pace than JEE specs. This means I get a lot more features that are useful to me now years before they show up in JEE.

I don't think reality is quite so simple. I've seen it myself in being a Java EE adopter from the start. Not even counting releases prior to Java EE 5, innovations like annotations as a replacement to/default over XML (a pretty big one for most people), intelligent defaults/convention-over-configuration (Spring still has way too much explicit configuration for very common use-cases), EJB @Asynchronous, EJB @Scheduled, declarative conversations, CDI producers, CDI qualifiers, declarative bean validation, WebSocket/HTML5 support, declarative REST, declarative SOAP, etc were introduced in Java EE. Java EE ecosystem implementations and add-ons like OpenShift, Seam 2, Seam 3, DeltaSpike, Arquillian, Forge, PrimeFaces, RichFaces, AeroGear, Hibernate, EclipseLink, Jersey, RESTEasy and many, many more match the evolution of Sping alone if not outpace it (just makes basic sense -- one vs. many).

The questions around Spring's future is not entirely unfounded either. VMWare bought SpringSource to make money. Now they decided the SpringSource unit products/services are a hard sell. That can't possibly be great. With Java EE, you are not so bound to the ups-and-downs of a single company because it's an open technical standard...

All views voiced are my own, not necessarily Oracle's.

The fundamental problem with JEE is its monolithic nature that ties to you to a monolithic server that is on a 4-year release cycle. Here are some of the problems with this approach.

1) No two users of JEE use it the same way, over the past 12 years I some times I have used messaging some times not, some times I have used SOAP some times not ... etc. JEE Profiles are fundamentally useless because they are not definable by the end user.

2) You really need to be able to run every technology outside of the container and JEE assumes that there is always a container, which has been a huge pain for JEE, developers for ages. It’s great that some things like JPA run outside the container without that there is no way I would be using JPA today.

4) Tying the life cycle of individual specs such as JPA to the release of the large JEE spec is a big mistake and leads to a lot problems. Lets take a simple example of this.

JPA 1.0 came out in 2006 with EJB 3.0, JPA 2.0 came out in Dec 2009 that is three years between releases of JPA. JPA 2.1 will show up sometimes in 2013 another three years between releases. There are many things that JPA does not do such as stored procedures, which are really needed. People were using stored procedures for decades but it will only have taken JPA 7 years to add support for stored procedures.

This means that when using JEE there is no such thing as a real world app that is 100% JEE you always end up having to use some features of the underlying implementation such as hibernate to do things that are very common but are missing from the standard.

It would be much better if JEE took a page out of the eclipse playbook. JEE should be a spec that defines how to stitch together an application server out of plugins that implement standard interfaces. Then let the various specs evolve independently.

As I user I want to decided what goes into my app server not the vendor selling me the app server. As a user I want to be able to get the jee6 core platform and install the JPA 2.0 plugin and JAX-RS plugin and ... etc without having to care or worry about the parts that I don't care about.

Also this way new specs can enter and exit the ecosystem faster. If a spec is bad and the community moves on to something better old users would still be able to install it as a plugin into their app server and not have to rewrite their code. New users just ignore the bad spec / api and let it die from disuse.

With a modular approach to JEE things like JMS could have been revised much earlier to simplify the API instead of waiting 10 years between revisions. Another benefit is that the dropping of eagerly awaited feature just before release does not have to happen, let each spec release on its own cycle and we will have a healthier ecosystem.

5) JEE focus on specific problem domains like persistence, transactions, and security is robbing the community of a standard generalized solution to these problems which can all be handled much more generally with Aspects and Aspect Oriented Programming.

I am not suggesting that the Java Language be extended to absorb the features of ApsectJ.

Binary code weaving is a very powerful generalized mechanism yet there is no standard way to do this in the JSE or JEE. Every major framework out there uses some sort of byte code engineering library. The end result is that most JEE apps end up with Javassit, CGLIB, ASM explicitly on the classpath, and ASM and CGLIB repackaged with JARJAR a couple of times, some frameworks like OpenJPA argue that you really need to have a java agent to get the level of bytecode engineering needed to build nice easy to use api.

I wish JEE would just take the ApsectJ @Aspect annotations and the binary weaver and just make them part of the spec give us a generalized solution to cross cutting concerns, not just domain specific things like here is how to do transactions, here is how to do security, here is how to do persistence.

6) JEE does not care about developer productivity maybe in marketing brochures they say things like we care about developer productivity but actions speak louder than words.

Case in point JEE7 will not have a data binding framework for JSON (my impression watching the JEE keynote video from JavaOne) which is really disappointing, I currently use Jackson2 and I would really hate to have to manually write code to parse JSON just to be JEE compliant that would kill my productivity. So if JEE cared so much about developer productivity where are those API's that are going to save me time and effort with today's problems not yesterday's.

I am concerned about SpringSource because while spring is open source the development is not really all that open, for example there is no public developers mailing list where you can watch the spring being cooked up by its developers.

I am NOT saying that Spring is better than JEE. What I am saying is: The way JEE is being developed is not really addressing the needs of the community thus forcing the community to turn to solutions like spring.

VMWare bought SpringSource to make money. Now they decided the SpringSource unit products/services are a hard sell.

I see how we get divided in two: Pro-Spring and Pro-JEE. Unfortunately what I don't see is an objective look at the two of them. What are the pros and cons? Frankly, I start getting sick of any form of evangelism where people are praising a religion just because they have some interest or incentive or because it's their JOB (Oracle employees or SpringSource affiliates).
I can say that I am in the middle (not married to Oracle or VMWare): I begun with J2EE and lived the pain of doing simple things in a complicated manner (who worked with BMP/CMP knows what I am talking about) then I switched to Spring (as Steve Jobs was saying - felt like a "glass of water in hell") and now I am thinking to adopt TomEE (so maybe go back to the standards a little bit).

So, in the end, for all the evangelists: why don't you just stop buzz wording left and right and show to the community some REAL applications (not just the toys you use for demos) with some true benchmarks (e.g. how many lines of code has a project implemented with Spring has versus a project implemented with JEE).

In the end, if I am allowed for an opinion: if springsource would somehow patent all the ideas they came up with (take CDI as an example), JEE nowadays will be still J2EE. I am in software industry for more than 10 years and whenever I see something coming from Spring I remain pleasantly impressed and ask myself "when will they place this in JEE?" When I see a new JEE release, frankly it doesn't impress me at all.

You are correct that there is no public developer mailing list for Spring, however, all active code development is on github [1], features and bugs are in a public JIRA [2], community questions and discussions are in the forums [3]. All of these resources are monitored and maintained by the SpringSource engineers, who also discuss roadmap and plans very openly at many developer conferences and SpringSource webinars. SpringSource engineers are always happy to hear feedback and receive pull requests from the community.

[1] github.com/SpringSource/spring-framework
[2] jira.springsource.org/secure/Dashboard.jspa
[3] forum.springsource.org/forum.php

Josh I am very familiar with the Spring JIRA I have filed a few bug reports, and feature requests. I am familiar with the forums and the code on git hub. All these things are great and needed.

However, the development process for spring projects is not really open and users can't see the conversations between developers to gain visibility into the direction / roadmap of where spring is going or even to participate in those discussions ... etc.

There is no place to see the names of the people on the spring development team, who is active who is not. Simple things like how many developers are employed by spring source vs being independent. Is the fate of the spring framework tied to profitability of spring source?

Take spring social it seems to be stalled, the LinkedIn plugin for spring social hit RC1 on Feb 21 2012 now it is December 2012 and Spring Social LinkedIn 1.0 has not be released yet. As a user of spring social this bothers me a lot, but since there is no developers mailing list it is not clear how one gets involved to help out on something like this.

While the various spring projects are under the ASL as an outsider it feels like spring development is internal to spring source.

BTW, what I stated has been widely reported, including on major finacial news written by well respected industry analysists: stocks.rcrnews.com/rcrwireless/news/read?Symbol....

All views voiced are my own, not necessarily Oracle's.

A few things to think about:

* GlassFish has a release cadence of roughly twice a year - precisely because our community wants it. WebLogic customers seem to prefer slower release cycles. You should choose an implementation that matches your needs.
* Most APIs are indeed usable outside Java EE. However, the end goal of Java EE is to provide a unified runtime like .NET/RoR, not just a bunch of libraries. That goal resonates with the vast majority of Java EE adopters. If you don't use an API provided, big deal -- it's just a few jars in the file system. That's far better than bloating up with hundreds of jars per application.
* All APIs are indeed on their own release cycle. It's entirely up to indivual EGs when a JSR is released.
* No standard provides a guarantee of 100% portability. To force that would have a chiling effect on innovation. The goal is to maximize vendor neutrality as much as possible. That's still far better than having 100% of your code tied to a single vendor. Now, in case of JPA (which is widely used -- just look at the Producitivity report Josh referred to) the vast majority of JPA code that I've seen over the years is highly portable.
* We have been consistently told interceptors are a much more simple, developer-friendly cross-cutting concern paradigm than AspectJ.
* In my own experience as well as in the Java EE adopter stories I referenced earlier, the common consensus is that Java EE is highly productive, perhaps more so than Spring.
* The biggest lesson from EJB 2.x has been that it is not a good idea to standardize in a hurry. The JSON-P folks felt strongly that they should get the basics right for JSON processing before taking on JSON binding. It's hard to fault them for that.

All views voiced are my own, not necessarily Oracle's.

Please note that I've been advocating Java EE long before I had anything to do with Oracle or evangelism as a job (in fact the same is true of Josh). I do it because I see Java EE as a great technology. In fact, I think J2EE was a great technology in it's time (which was literally a decade ago). The only real problem has been not adopting DI, Hibernate/JDO and embedded containers/testing quickly enough and taking too much time with Java EE 5 (a mistake the Java EE management openly acknowledges).

Now on to more relevant/technical concerns:

As to code examples -- there are plenty for GlassFish (glassfish-samples.java.net/). If you are an experienced developer, it's not at all hard to see how it would look like for a real world application. You can also look here: www.rahmannet.net/downloads/spring_javaee_compa... (up-to-date until Java EE 6/Spring 3.1). I also ported the DDD sample application written in Spring 2/Hibernate 2 here: blogs.oracle.com/reza/entry/java2days_2012_trip.... The ultimate is of course success stories in the real world: blogs.oracle.com/stories/.

As to your remark about "not being impressed" with Java EE, I'd be interested in hearing exact details, specifically on Java EE 7 (I've already provided concrete examples of innovation in Java EE that then has been largely adopted by Spring). What do you believe could be better?

As to SpringSource "patenting" the ideas in CDI, you can't patent prior art. DI far preceded Spring. In fact Guice, Seam and CDI DI is quite different than Spring: blog.crazybob.org/2006/01/i-dont-get-spring.html.

All views voiced are my own, not necessarily Oracle's.

BTW, you can get very deeply involved in any Java EE spec via programs like Adopt-a-JSR: blogs.oracle.com/theaquarium/entry/adopt_a_java....

All views voiced are my own, not necessarily Oracle's.

My JBoss buddies reminded me of the Kitchen Sink Java EE/JBoss AS demo app: www.jboss.org/jdf/quickstarts/jboss-as-quicksta... :-). It's also a great resource for seeing how a realistic Java EE project looks like...

All views voiced are my own, not necessarily Oracle's.

I am Spring and JEE user I am not an evangelist for either company.

"We have been consistently told interceptors are a much more simple, developer-friendly cross-cutting concern paradigm than AspectJ."

"No standard provides a guarantee of 100% portability. To force that would have a chiling effect on innovation. The goal is to maximize vendor neutrality as much as possible. That's still far better than having 100% of your code tied to a single vendor. Now, in case of JPA (which is widely used -- just look at the Producitivity report Josh referred to) the vast majority of JPA code that I've seen over the years is highly portable."

The biggest lesson from EJB 2.x has been that it is not a good idea to standardize in a hurry. The JSON-P folks felt strongly that they should get the basics right for JSON processing before taking on JSON binding. It's hard to fault them for that.

Just for sake of clarity, I do realize you are trying to be objective :-). I'm simply pointing out what you might be missing...

Interceptors are indeed intended to be the general purpose cross-cutting concern solution for Java EE. That's why they are being expanded in Java EE 7 (in fact the new JTA 1.2 declarative transactions are based on it) and potentially even to Java SE via CDI 2.0. If you have specific ideas on how it should be enhanced, it's definitely worth discussing in the CDI EG. AspectJ is simply a non-starter. It's way too complex for anything Java EE...

JPA did not support stored procedures primarily because the entire stored procedure notion is a little anti-ORM. As a consultant, I moved folks away from that model to Java centric ORM! In fact, most Hibernate projects I've seen just don't use stored procedures although the support has been there for yaers. Stored procedures are definitely outside the 80% use-case for ORM...

As to JSON-P, I already explained that the issue there is not technology maturity. It's about taking the time to get the fundamentals right (basic processing) before making bigger leaps (declarative binding). There is of course nothing stopping anyone from leading a JSON binding JSR, it's just that it makes little sense without having a standard for processing is the first place (which we now do). It's also important to remember that a standard isn't just a Javadoc and a PDF. There's the reference implementation (which we strive to make production ready for GlassFish/WLS) and the TCK. Doing all that takes a reasonable amount of time. Let's also remember that these folks went though the human element of a major acquisition by Oracle...

As to the folks behind JAXB, Jackson, etc there is no question they would be engaged for a subsequent JSON binding JSR. For every JSR, the spec leads make a reasonable effort to recruit relevent experts in the field -- JSON is no exception...

All views voiced are my own, not necessarily Oracle's.

That’s great that you’d like to get involved, thanks! We appreciate it. A public email list isn’t a gating factor to doing so at all.. in fact, the 25+ community members who’ve made contributions to Spring Social have all seen our “get involved” directions (which are posted in multiple locations (the documentation, the forum, the GitHub wiki, etc), on how someone could get involved. If you read the most recent “This Week in Spring”, or sign up for the newsletter – you’ll see mentions of the community contributions. Regarding project activity - just a few weeks ago SpringSource released 1.1.0.M1 for Spring Social Core/Twitter/Facebook – it’s an active project that has big plans for the future. Those plans are actively and openly discussed on the forums, so fire away! That’s probably the best place for the level of engagement you’re looking for, and you’ll make the direct connections with the engineers you need to from there. Also, JIRA has a project roadmap that is publicly visible.

As for getting plugged into the project, there are several ways:

- Join in on the forum
- Contribute bugs/issues/improvement ideas in JIRA, which it sounds like you may be doing already
- Fork the projects on GitHub, make changes, and submit pull requests
- make sure to review the contribution guidelines

Enjoy and thanks for contributing!