Spring Migration Analyzer: An Assistant For JavaEE To Spring Conversion

SpringSource has introduced the first milestone of Spring Migration Analyzer. This is a helper application that scans a JavaEE artifact and creates a summary report of APIs and classes that need extra attention if this application is to be migrated to Spring. This report can assist the migration evaluation since it can be used as an estimation tool for the effort needed to migrate.

Spring Migration Analyzer is offered as a command line utility that can be used on an OS with a JVM installation (it uses Java itself). It takes as input the binary deployment of an existing application (such as a war or ear file) and it creates as output (in a separate directory) an HTML report. The report contains a list of the JavaEE technologies detected, along with advice on effort required to migrate them to Spring/Tomcat. There is a general overview section but one can drill down to individual classes and see how they affect the migration effort (if they use a specific JavaEE API). The technologies in question are:

Spring Migration Analyzer also detects additional features such as the type of EJBs (e.g. Session vs Entity), Spring libraries, vendor specific deployment descriptors, and even programmatic usage of transactions. For each technology detected there is a textual description on how/if it affects Spring Migration. The rest of the report contains the detailed structure of each class file found in the application, such as fields, methods, java imports, exceptions thrown etc.

Notice however that running the Analyzer with default options is not very helpful as the report contains a lot of false positives. The main reason for this is that because it deals with the binary artifact and not the source code, it does not distinguish between the actual code of the application and the code of external libraries. It would be ideal if the report excluded external libraries and only focused on the source code created by the developers (the same code that most other software reports deal with e.g. unit tests, code coverage, quality tools).

For example, a very simple application that uses Logback for logging is reported as if using JMS:

There is no JMS code in the source code, it is just that the logback binary also contains JMS imports since JMS is supported as a logging target. Therefore in order to get meaningful results you must also use the "exclude" command line switch to discard information of external libraries (for example the /WEB-INF/lib directory). Also the output directory cannot be the same as the input one.

So while in theory the command line switches of the utility are optional, in practice they are required. In summary at its present state Spring Migration Analyzer is a useful idea but needs some tweaking on how errors are reported to the user.

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.

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...

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...

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.

Unless you are a VMware executive or work in the strategic planning team at EMC or VMware, you have absolutely no knowledge about the business reasons for VMware's acquisition of SpringSource or the results of its individual business units. Please stick to discussing technology and restrain yourself from wasting everyone’s time with FUD that’s not based in fact. You are welcome to your opinions of course, but to assert that you have some factual knowledge about the SpringSource business within VMware is just the type of falsehood that you usually are so eager to accuse others of.

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.

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.

* 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.

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).

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?

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

How many Java developers understand Java reflection, JNI, Dynamic Proxies, class-loaders, the Java Memory Model, Strong vs. Soft vs. Weak vs. Phantom References? Yet these are the essential tools for building the application servers and frameworks that we use. Most java developers don't need to know these things. Because they are using higher level apis? My arguments is that things like Interceptors, and declarative transactions, should be built on top of a general purpose weaver that is part of the system that is accessible to anyone who wants to use it. How is adding choices for the end users harming simplicity? Should we all go back to using COBOL its simpler than JEE?

With a general purpose Weaver you can build a lot of nice API, and make the job for the people writing those API's easier, typical users won't even know that it is there just like the don't know many things about low level Java programming.

"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."

I was not complaining about the portability of JPA I am very happy with that. I was pointing out that JPA lacks supported for stored procedures for the past 7 years, when every database out there supports stored procedures. I don't see how adding support for stored procedures should take 7 years.

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.

Why don't the JSON-P folks figure out how to recruit the people who created Jackson, or JAXB, or any number of data binding frameworks. This supports my claim that Oracle and the JCP does not do a good job of engaging with leaders of the open source community to deliver good solutions in a timely manner. I buy the too early to standardize argument for things like cloud but not things like data binding for JSON when there is already JAXB, JPA. We are talking about a well understand simple data transfer format. The argument that a JSON API is hard to get right is really hard to accept.

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...

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