54

I'm confronted with a situation...

I've been asked to give an advise regarding which approach to take, in terms of Java EE development between Spring 3.0 and Java EE 6.0. I was, and still am, a promoter of Spring 2.5 over classic Java EE 5 development, specially with JBoss, I even migrated old apps to Spring and influenced the re-definition of the development policy here to include Spring specific APIs, and helped the development of a strategic plan to foster more lightweight solutions like Spring + Tomcat, instead of the heavier ones of JBoss, right now, we're using JBoss merely as a Web container, having what I call the "container inside the container paradox", that is, having Spring apps, with most of its APIs, running inside JBoss, So we're in the process of migrating to tomcat.

However, with the coming of Java EE 6.0 many features, that made Spring attractive at that time, easy deployment, less-coupling, even some sort of D.I, etc, seems to have been mimicked, in one way or the other. JSF 2.0, JPA 2.0, WebBeans, WebProfiles, etc.

So, the question goes...

From your point of view, how safe, and logical, it is to continue to invest in a non-standard Java EE development framework like Spring given the new perspectives offered by Java EE 6.0?

Can we talk about maybe 3 or 4 more years of Spring development, or do you recommend early adoption of Java EE 6.0 APIs and its practices?

I'll appreciate any insights with this.

Simeon Leyzerzon
  • 18,658
  • 9
  • 54
  • 82
Jose Diaz
  • 5,353
  • 1
  • 31
  • 29

4 Answers4

70

The crucial point IMHO is not the one of features. In that regard, Spring will always be ahead of JavaEE as it's natural for OpenSource VS. a Standard. So one fact is, that you get the new features much earlier with Spring that with JavaEE (e.g. container integration testing is a new feature in JavaEE 6 and has been available in Spring for ages).

The most important point IMHO is the one of lifecycles for administration and development. When you choose JavaEE, you tie your programming model to your infrastructure. Usually app server vendors are not the fastest adopting new standard's versions (blame WebSphere, JBoss, what have you). So this means we probably won't see production ready, JavaEE 6 supporting products by the big vendors before end of the year.

Even if that is the case then you still have to take the hurdle of your administration, IT department and budget controlling managers to be willing to upgrade to this shiny new version. Coming from this side, JavaEE 6 is not even an option to many shops. You can choose what ever you like to deploy your apps to? You wanna choose Glassfish for production? Go ahead, try. Most shops aren't in such a "comfortable" situation.

Exactly contrary: Spring. Decoupled programming model from infrastructure. Go take current 3.0.x and use @Inject, JPA 2 and the like in your Tomcat or legacy application server.

Oliver Drotbohm
  • 80,157
  • 18
  • 225
  • 211
  • 5
    So, basically, you're saying that if you can't choose for an up-to-date java ee server, you should go for spring? Well, my minimum requirements include being able to have an up-to-date app server. Spring ties you to Spring. Java EE ties you to any of the 10+ standard app servers. – ymajoros Aug 27 '12 at 05:38
  • 13
    … exactly the same app servers you can easily deploy Spring applications to, as well. My key point is that tying the programming model to the app server is a problem in long term as what looks like choice in the first place becomes a burden when upgrading. You can use JSR-330 annotations in your app and simply use Spring as runtime container if coupling really is an issue. With Spring you gain decoupling from the deployment target and thus an easier update path for your runtime that does not necessarily have to involve IT operations (it can/should, but it doesn't require buying a new server). – Oliver Drotbohm Aug 27 '12 at 20:19
  • 2
    There is still one big difference. If you want to remove Spring, some work is needed (I'd say: a lot). If you want went standard and want to change app server, you shouldn't need to touch your code. – ymajoros Aug 28 '12 at 05:55
  • 10
    Wow, I wonder this myth is still around. Have you ever tried just to port a non-trivial JavaEE application using JPA from one app server to another? That's yet another issue I see with the JavaEE space: it implies flexibility where there in the reality is none (once you've decided for an app server you're stuck with it) and does not provide flexibility where it's much more likely needed (persistence besides JPA? Sorry, nope…). Ironically Spring apps are much more portable from one app server to another as you keep the programming model with the code, not the infrastructure. – Oliver Drotbohm Aug 28 '12 at 14:47
  • 8
    I really did, from Hibernate to Toplink Essentials to Eclipselink, from OC4J to GF. This is really no problem since JPA has been around. Please tell me, what JPA feature differ between implementations? I know about some implementation bug from time to time, but it's rather an exception. It really works. Did *you* try? You are spreading the myth that it doesn't work half of the time. If you keep everything in your app libs, guess it will be easy to switch to another server. That's not what I call portable, and I still don't see any benefit being bound to Spring and not being able to change – ymajoros Aug 28 '12 at 19:58
  • I have seen no problems when moving JavaEE6 applications from one app-server to another (all used JPA2). – Ville Myrskyneva Feb 17 '14 at 08:11
  • Wow, politics is present @ SO as well... Looking back, one can safely say that so far Oliver has been proven prescient and Spring has won. To the point they are now (in desperation) trying to regain the market share and re-brand it to EE4J. Would be interesting to see where it all leads. – Simeon Leyzerzon Oct 03 '17 at 18:52
12

If you're already a Spring shop, why bother switching? You're happy with it, it does what you want, it's actively developed, you're probably not looking to run outside of Tomcat any time soon, if ever, since Tomcat is very mature, and runs everywhere. So, any promise of portability that Java EE might suggest is right out the window.

I see no reason to switch away from Spring.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Will Hartung
  • 115,893
  • 19
  • 128
  • 203
  • 3
    Because Java EE is portable, and you're not bound to Tomcat. Really. Why do so many people that Tomcat is the easy way? Already tried to install latest Glassfish 3, for example? It's just as easy, if not easier, but is standard. Like: multiple people gathered to define how things should work; it's easy to switch; you don't need to reinvent the wheel and reimplement things that are already provided. – ymajoros Jul 30 '12 at 20:00
8

Since Will and Oliver already said the most crucial stuff I'll only add that: "if it works and does the job done, then leave it alone!". "Newer" and "standardized" doesn't always equal "better", in fact it rarely does - new things are clunky and buggy and (that's the most important to me) not widely supported. If the rest of Java EE 6 is as "standardized" as JSF2.0 (and all the Rich/Ice/Prime/WhateverFaces), then believe me stick to Spring for now. A lot of companies stick to a bit older technologies for a reason (stability > *), Spring's been on the market for years and is well established.

@Edit: Especially for @ymajoros: JSF (both 1.x and 2.x) is a flawed standard due to multiple reasons and is useful only in a handful of cases (i.e. when you are creating small, simple CRUD websites or when you're a Java EE enthusiast):

  • creating new components is a pain in the ass. Since it is a component based framework I would assume it would make things easier not harder. Currently I prefer to go with a JS+Java on the backend approach since it is actually easier for me to create components there. The only saving point of JSF is that there's a ton of components libraries. Problem starts when they don't work, you want to change something or create your own component.
  • exception handling is a mess (or did something change in the past year or two?)
  • JSF has problems with being too stateful - few bad decisions, one bad dev in your project and half of your app can be stateful and serialized.
  • the UI part of the standard does not (or at least didn't when I wrote this answer) cover most collections from Java (in fact only decently covered data structure was a List).

As for the standard which you are so fond of: did they at last somehow integrate JSF with JAX-RS? Because last I checked those specifications were totally separated even though you could make a lot of improvements. For instance why can't I annotate a method with @Path in my backing bean so it would be both handled by a REST request and a JSF request?

Maybe some (all?) of those issues are now fixed but when I wrote this answer they were but few among all the bad things about JSF and the standard in general.

Currently if I want to create a very small, simple CRUD app I go with Play 2.0 (even though it is one huge anti-pattern) or something like RoR. When I want to create a large, "enterprise level" app then I grab a JS framework (like ExtJS) and a JS component library combine it with Java backend (and for instance Spring) and I do what I need without any overhead this so called standard would bring.

Of course there are cool parts of JEE6 like JPA2, JAX-RS2, bean validation isn't all that bad. But using the whole standard stack only because they called it a "standard" (and as I mentioned above most of the specs don't even synergize) is, in my very humble opinion, just wrong.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Mateusz Dymczyk
  • 14,969
  • 10
  • 59
  • 94
  • 2
    Please back up your claims. Buggy? Is Spring less buggy than Java EE 6 implementations? Why would it be? Spring has only 1 implementation, Java EE 6 has plenty. Regarding JSF 2: it *is* a standard (nothing loose about it), Prime/RichFaces etc. are component libraries. – ymajoros Jul 30 '12 at 19:56
  • 1
    yes, 2 years ago JavaEE6 was clunky and buggy. Now it changed significantly but I still probably would not use it (although there's the EE hype going on right now). JSF2 is a poor standard which is a pain to develop with and is always behind other technologies. Well like all standards... Next time please check the date since 2 eyars in CS is an eon. – Mateusz Dymczyk Jul 31 '12 at 07:01
  • 3
    You didn't give any argument: why poor? behind what? I guess this kind of holy wars hasn't any place here, I'll stick to the *facts*: java ee/jsf are standards. – ymajoros Aug 27 '12 at 05:34
  • @ymajoros: well sorry for not replying in the comment but my reply was too long so I simply edited my answer. – Mateusz Dymczyk Aug 27 '12 at 09:11
  • 1
    I just plainly disagrees, don't know when you used jsf for the last time. You mention some claims, not facts. This isn't a so answer, it's a discussion. Knowing that you'd prefer RoR to JSF isn't adding value. – ymajoros Aug 27 '12 at 09:39
  • 1
    Plus, it's not only "called" a standard, it is one, as in: multiple people gathered and agreed on it and there are multiple implementations. – ymajoros Aug 27 '12 at 09:41
  • Which ones are claims not facts? Also as Olivier said I am not really tied to spring since spring can use most JEE annotations. The only time you get tied to it is when you are using spring specific things and that happens only when the standard simply does not have them yet (or does not want to have them). – Mateusz Dymczyk Aug 27 '12 at 10:01
  • Finally as you can see the question states: "From your point of view". This is my point of view, you can disagree but you, yourself, did not say a single good thing about JEE so I do not see why I should change my opinion. Well sorry your only claim so far was that when using JEE you're not tide to one implementation. I still don't see the benefit behind this as they all implement the same specification so you'd want to change to a different one only when the current one you're using breaks. So far my spring implementations did not break that badly I had to think about switching. – Mateusz Dymczyk Aug 27 '12 at 10:03
  • 2
    "creating new components is a pain in the ass" is just an opinion. "exception handling is a mess (or did something change in the past year or two?)" --> it did change in Java EE 6. "flawed standard", really? That's quite biaised. All of this are just unbacked claims, I suggest to remove those parts. – ymajoros Aug 27 '12 at 10:30
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/15841/discussion-between-ymajoros-and-mateusz-dymczyk) – ymajoros Aug 27 '12 at 10:36
1

I think you will have noticed working with Spring makes you more productive than Java EE. I don't think they will ever be able to make the pig (Java EE) really fly. Java is a great language/platform, don't cripple it with Java EE. Why settle for 'some sort of dependancy injection', if you can today have Spring?

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Maarten Abbring
  • 41
  • 1
  • 9
    J2EE is from another time, it's been Java EE for years. And yes, you can be very productive with it (+standard). You "answer" is not an argumented one. – ymajoros Jul 30 '12 at 19:52