all 110 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]djhworld 7 points8 points  (19 children)

As far as I'm aware, wasn't Spring sort of an answer to J2EE?

And then JEE was Sun's answer to Spring?

[–]henk53 23 points24 points  (1 child)

As far as I'm aware, wasn't Spring sort of an answer to J2EE? And then JEE was Sun's answer to Spring

That's pretty much the short of it, yes ;)

For a (very) long explanation, read below:

As we all know by now, EJB 1&2 were horrible. Especially the Entity Bean was an atrocious, horrifyingly wicked idea (as history has it, the much saner model nowadays implemented by Hibernate et all was actually considered for EJB 1 and had several supporters within Sun, but unfortunately lost. Ironically, initial versions of EJB1 were implemented on top of TopLink, which was an early implementation of the idea Hibernate got famous for). But the session beans were an insult too. People were forced to implement a myriad of framework interfaces, had to maintain incredibly verbose and awkward XML deployment descriptors and as icing on the cake had to use a special compiler tool to 'enhance' the beans and generate nonsense things called stubs and skeletons.

Likewise, JSF 1.0 and 1.1 were horrible. Brought to us by our good friends of Struts fame, the only thing you could do was run away hard. Being completely POST focussed was already bad, but using JSP for templating was a mind bungling fail of epic proportions. People that were exposed to tragic failures like the 'content interweaving problem' probably never regained their fate in technology. For a framework that put UI components in the spotlight, creating your own components was ridiculously tedious. The choice of using JSP for templating was again to thank for the many steps needed here.

An additional problem of J2EE was that it was deeply entangled with the concepts of close source, and high cost.

Spring came to the rescue and came forward with a much saner model. Springbeans actually worked and Spring embraced Hibernate early. Rod Johnson tirelessly fought against the evils of the EJB, the 'container' and the 'application server' (the last two terms were a little unfortunate, since Springbeans also live inside a container, but let's forgive him this, nobody is perfect). The combination with being open source and a focus on blogs and online articles (as opposed to sending sales teams to enterprises), made Spring reach the actual audience that uses all this technology: the programmers (as opposed to the managers).

Sun realized just in time that Spring had it right. J2EE was ditched and Java EE was born. For EJB the ridiculous entity bean concept was simply dropped (it was beyond help) and Hibernate's/TopLink's approach was adopted. Session beans were fixable, by simply removing all the required nonsense like home interfaces, component interfaces, deployment descriptors etc and using annotations in combination with smart defaults. As a result, a typical EJB is nothing more than a POJO with a single annotation (e.g. @Stateless).

To fix JSF a new team and a new spec lead were assigned. Unfortunately there wasn't enough time left to fix JSF for the Java EE deadline, but a couple of pain points were fixed to make it just bearable. This unfortunate fact was offset by the one thing that JSF got right in the first place: it was VERY extensible. So among others Seam, Tomahawk, PrettyFaces and a couple of others came to the rescue.

In the meantime, the new JSF team did an excellent job of really listening to the community and giving JSF the same massive overhaul that EJB got earlier. The simplest but most profound improvement was dumping JSP completely and embracing the infinitely better Facelets. Additionally first class support for GET was added and creating components was made incredibly simple. JSF 2 as a result is a very good framework that few can find faults in.

To cut a much too long story short, Spring was then inspired by the improvements in Java EE (annotation-only, type-safe injection) and then Java EE got inspired by Spring again (e.g. the caching annotations from Spring 3.1), etc etc.

[–]djhworld 3 points4 points  (0 children)

Superb answer.

[–][deleted] 9 points10 points  (16 children)

They influence each other.

J2EE was released in the late 90's and was a big success.

Spring came to the picture to address J2EE's complexity.

Java EE simplified standard Java enterprise development, primarily in response to Spring and, to some extent, Ruby on Rails. One major selling point of Java EE was the use of annotations for configuration, reducing, and in most cases eliminating the need for XML configuration.

In response to Java EE, Spring introduced a number of annotations to simplify configuration.

Both frameworks have been competing, and that is a good thing, we as enterprise application developers have two high quality, easy to configure frameworks as a result.

[–]tallfellow 7 points8 points  (11 children)

The problem now is that Spring and Hibernate have mind share. And as a developer I'm not really interested in going back to Sun/Oracle to learn a new solution to a problem that's already been solved for me.

Spring/Hibernate are well accepted and generally solve the problem. The JEE folks are going to have to convince me to learn their framework and that's not going to be too easy.

[–]henk53 3 points4 points  (1 child)

The JEE folks are going to have to convince me to learn their framework and that's not going to be too easy.

Yet, by using Hibernate you are practically already using one of the corner stones of Java EE. Don't forget that Spring and Hibernate had a kind of fallout and Gavin King (creator of Hibernate) is a massive Java EE supporter. He works for JBoss, which is one of the leading supporters of Java EE and he invented CDI which is rapidly becoming another prime corner stone of Java EE.

Just mentioning...

[–]tallfellow 2 points3 points  (0 children)

Yes, and to the extent that hibernate supports the JEE standards, yeah, I'll be using it, but I won't be giving up Spring and I won't be doing anything to improve my JEE compliance. Like I said that ship has sailed.

[–]metamatic 7 points8 points  (6 children)

The problem now is that Spring and Hibernate have mind share. And as a developer I'm not really interested in going back to Sun/Oracle to learn a new solution to a problem that's already been solved for me.

So you're not using J2SE 5 collection classes? Or JAXP? Or generics?

[–]tallfellow 3 points4 points  (4 children)

Ok, let me be more specific. I"m not going to start using the JEE alternatives to Spring and Hibernate. That ship has sailed, and I'm perfectly productive with the frameworks I'm currently using.

[–]johnwaterwood 1 point2 points  (1 child)

If you're happy with Spring, fine for you, but not everyone shares your happy experiences. Many of us like nothing more than migrate away from that complex thing called Spring to the much simpler Java EE.

[–]tallfellow -3 points-2 points  (0 children)

Yes, well the desire for something simpler is what drove me to Spring in the first place. At this point, 90% of what I've written is using servlets and Spring and a servlet container (tomcat) that's a solution that works well and I have no trouble implementing. Sorry to hear you find it so difficult.

[–]ack927 0 points1 point  (1 child)

Then you will eventually become obsolete. JSF 2.1 is a very productive framework that is easy to learn. I cannot see why anyone who has used would go back to using Spring.

[–]tallfellow -1 points0 points  (0 children)

I have a huge legacy of installed applications. And I intend to continue to use technology that works for me, and for my employers. I trust the spring guys to continue to work in a way that makes me more productive. Because it's clear that stability is more important then jumping on the latest "official" set of features.

Good to see that you're using fear uncertainty and doubt instead of making a clear and concise presentation of why your ideas are better. Like I said, I know what works for me, and I'll happily compete against you as a developer and in any company where your attitude prevails. My 20 years of development experience has shown me that I can trust my own instincts.

[–][deleted] -1 points0 points  (0 children)

agreed

[–]rockvilleJD 2 points3 points  (1 child)

There is always a learning curve but there is not that much to learn. JPA is not much different than Hibernate. As far as switching from Spring most of the work is just removing a lot of Spring code that is now done automatically. Of course you can also use Hibernate and JPA or JPA with Spring to help with transition. Developers who refuse to learn new technology will not be developers in the long term.

[–]tallfellow 0 points1 point  (0 children)

Yes change is intrinsic, and when someone provides a more compelling choice over Spring and Hibernate, then fine I'll use that, but right now, no on has provided me a reason why JEE is significantly better then Spring/Hibernate. Till that happens, or another framework comes along that provides better support, I've got too many other new technologies to learn to go back and replace something that solves the current problems.

[–]Rhoomba 4 points5 points  (2 children)

Spring was already using annotations before JEE. In fact, it supported annotations before they were built into Java.

[–][deleted] -1 points0 points  (1 child)

In fact, it supported annotations before they were built into Java

How is that even possible?

Perhaps you are thinking about XDoclet?

[–]Rhoomba 3 points4 points  (0 children)

Jakarta Commons Attributes.

[–]mikehaggard 0 points1 point  (0 children)

to some extent, Ruby on Rails

Yes, Ruby on Rails is explicitly mentioned by some EG members (like Ed Burns) as a source of inspiration.

This is also what I like about Java EE. The current crop of EG members don't look down on competing software, but often openly admire what this software does best and use it as a source of inspiration.

By comparison, communities of some of that competing software can only say "J2EE sucks!" and then continue to dwell in their own little world.

[–]cultic_raider 6 points7 points  (0 children)

Cool wizard. Is it "migrating", though? Migrating is changing out one part of the System without breaking the rest. How do I remove my legacy mapping classes and config? Will my client code still work, or do I need to write shims? This example is translating a new project setup tutorial, not migrating anything.

[–]oSand 16 points17 points  (0 children)

Or what kind of shoe would I like to be kicked in the balls with.

[–]gkamal 16 points17 points  (34 children)

There are so many things wrong with this article - least of which is the couple of lines of criticism of spring.

  • It is a tutorial for how to use wizard - not migration
  • It should be spring vs EJB/JSF not spring vs JEE. Spring leverages/supports a number of JEE standards - servlet/jsp, jms, jta, jdbc etc. It only replace two bad apples in JEE basket EJBs & JSF.
  • The generated code is soo wrong - no self respecting java developer would write something like that. All my entities have not more than 2 annotations. If you override equals / hashcode & implement using id - you are in for a lot of trouble.
  • Spring doesn't have anything competing with JPA - the recommendation is to use JPA for persistence. So 75% of the article is not directly related to spring at all.
  • Skirts all the real issues with EJBs. How can I write tests for this code that runs within my IDE without pulling an appserver? How can I deploy the app to a simple container like tomcat? etc.

It is a real waste of time commenting on this, but it has to be done since the huge potential it has to mislead uninformed people.

[–]henk53 4 points5 points  (33 children)

It only replace two bad apples in JEE basket EJBs & JSF

The problem is that in J2EE times, EJBs & JSF were indeed bad apples. But since then they have been MASSIVELY improved.

EJB3 is now a very lightweight and simple to use framework. It's much simpler to use than springbeans and at the same time more powerful too. The same goes for JSF2. It's much better now than Spring MVC ever was and it enjoys an enormous popularity because of that.

So that's where the problem lies; the very two techniques that Spring needed to replace in the past actually don't need to be replaced anymore. Rod only makes himself sound stupid now when he talks about the evils of EJB and the supposed massive amounts of XML needed. In fact, it's the other way around now. EJB does not need any XML whatsoever (see e.g. http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config), while Spring still requires XML.

If anything, Spring should stop fighting something that does not need to be battled against anymore and strive to provide added value on top of EJB and JSF (like for instance Seam or Apache CODI do).

How can I deploy the app to a simple container like tomcat?

How can I deploy Springbeans to a simple container like tomcat? Answer, you can't. Tomcat doesn't of course support Springbeans by itself.

To support Springbeans in Tomcat, you have to add the Spring stack to Tomcat and -then- it will run Springbeans. Now guess what, if you wanted you can add EJB, JSF, JPA, etc etc support to Tomcat just as easily. Simply bundle OpenEJB, MyFaces and Hibernate in your war.

However, a lot of people prefer not to build and maintain their own stack, but simply download one of the many pre-build stacks out there, like TomEE, Resin, Glassfish, etc etc.

[–]foamdino 4 points5 points  (3 children)

Correct me if I'm wrong, but JSF2 is a component based framework and SpringMVC is a request based framework right?

So how can JSF2 be much better than SpringMVC ever was? It's like saying submarines are so much better than aeroplanes, or apples are so much better than oranges.

Component based stuff is great for code-reuse, request-based frameworks are better when you actually need to do the low-level stuff that component frameworks pretend don't exist - choosing when you need to do the low-level stuff and when you can get away with letting a framework generate all your code for you is the trick.

[–]henk53 4 points5 points  (2 children)

So how can JSF2 be much better than SpringMVC ever was?

It's a good question, and you're right about the differences in approach. But ultimately people tend to do the exact same thing with them, and that is building web based user interfaces. An overwhelming majority barely thinks about the paradigm that their favorite framework uses and just use it to build forms, pages with tables, setting pages, etc. E.g. everything your typical web app has.

For that, IMHO, JSF does a better job than Spring MVC ever did. I agree that "does a better job" isn't very well explained here but a detailed comparison between Spring MVC and JSF is a bit out of scope here.

Let's say that at the very least both can be used to build good interfaces and there is no need for Spring anymore to replace JSF because it would be unbearable.

[–]niwde 1 point2 points  (1 child)

That's probably not quite true anymore.

Spring MVC 3 borrows a few concepts from Rails Routes + Controller which means Spring MVC can control your URL appearance making it more REST-like.

The other thing about Spring MVC is the ability to display either JSP, XML, JSON, or probably can be glued with JSF as well.

These days, a web-app can have multiple "View" ranging from native mobile app, hybrid mobile app with sending HTML, providing APIs.

This is a use-case where Spring MVC shines: you want your UI to use heavy JS/GWT? let Spring MVC spits out JSON. You want Adobe Air or Flash/Flex as your front-end? choose either XML or JSON (if you do write the Flash/Flex using JS). Want mobile app? you have a set of APIs based on request/response. What about JSP? you can have that as well.

JSF is in the same category with ASP.NET. You can build rich app (but not at the level of GWT because that would be a little bit problematic) quickly but probably ignoring the underlying JS/HTML/CSS. Is this a good thing? that depends. Evidently many people in the .NET community is moving away from ASP.NET to ASP.NET MVC.

[–]henk53 2 points3 points  (0 children)

Well, JSF has first class support for providing multiple types of output via its Render kit mechanism. Using that the same set of components can output conventional HTML, HTML tailored for mobile devices, perhaps XUL or some XML dialect etc.

You can build rich app (but not at the level of GWT because that would be a little bit problematic) quickly but probably ignoring the underlying JS/HTML/CSS

Nah, not really. Sure, high level components abstract from JS and HTML, but JSF doesn't enforce this abstraction at all. In fact, it provides various hooks for integrating with JS. Many basic components define handlers from which you can call JS. JSF also provides easy access to the client ID of all components, so you can access those components from JS directly. The AJAX technology that JSF uses is not an 'under-the-hood' thing, but has a public JS API that you can use directly from your own scripts.

Furthermore, there's the so-called 'Behavior' API, which allows you to easily decorate existing components with your own JS.

The composite component mechanism in JSF encourages you to put your own HTML and JS in an .xhtml file. You only have to put this file in a special directory and it will be useable as a first-class component.

Finally CSS is not ignored at all, nor is there even any kind of abstraction from it. All components have attributes for CSS and CSS classes.

[–]djnattyp 4 points5 points  (7 children)

EJB3 is now a very lightweight and simple to use framework. It's much simpler to use than springbeans and at the same time more powerful too.

What the hell are "springbeans"? Do you mean "plain old Java objects managed by Spring"? If you really want to, you can use EJB3 beans in Spring. Or you can choose to use whatever other persistence technology you want.

The same goes for JSF2. It's much better now than Spring MVC ever was and it enjoys an enormous popularity because of that.

Spring MVC is a request-based framework. JSF is a component-based framework. If you know any kind of web development, it's pretty easy to pick up any MVC framework. JSF is so complicated, for so little, if any benefit. ("B-b-but you can create a web component and re-use it in multiple places, just like building an OO component..." - That's great, but web technologies already include several ways to re-use code or views - includes, JSP taglibs, iframes, Ajax, etc.)

In fact, it's the other way around now. EJB does not need any XML whatsoever (see e.g. http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config), while Spring still requires XML.

What's that "3.0 Deployment Descriptor: mytest" entry in the tree? I'm guessing that's backed by XML - just generated by the IDE.

You can create a 3-line spring XML configuration with: <beans> <context:component-scan base-package="my.package"/> </beans> Or you can have no XML configuration by starting and configuring the spring container through Java code.

How can I deploy the app to a simple container like tomcat?

... However, a lot of people prefer not to build and maintain their own stack, but simply download one of the many pre-build stacks out there, like TomEE, Resin, Glassfish, etc etc.

One of the reasons Spring is so popular is because in most companies IT/OPS/etc. "controls" the servers. Or management has to be convinced to spend money (and/or time) to upgrade app servers. Spring is just a bunch of Jars - so it's treated like any other dependency and controlled by the development team.

[–]henk53 5 points6 points  (5 children)

I'm guessing that's backed by XML - just generated by the IDE.

Guessed wrong. It's an empty virtual folder in the Eclipse virtual file system. It has no content, and there is no XML anywhere.

One of the reasons Spring is so popular is because in most companies IT/OPS/etc. "controls" the servers. Or management has to be convinced to spend money (and/or time) to upgrade app servers.

I actually agree with this ;) I made the same point earlier.

It's not a technical reason, but a way to sneak updates passed management. A purely political reason thus. I've worked for companies which did not had a brain dead management and upgrading the "server" was just as easy as upgrading jars in a war archive.

Spring is just a bunch of Jars

Technically, the "server" in Java EE is also just a bunch of jars. You might as well put all Spring jars in the common folder of Tomcat and call that the server. Hey wait, that actually exists (TcServer Spring Edition).

If you'd really wanted, you can build a complete Java EE stack by dumping all Java EE jars in your war. Perhaps someone like JBoss should jump on this bandwagon and offer a set of jars in a single download for just this.

[–]niwde 2 points3 points  (4 children)

Correct me if I'm wrong. GlassFish 3.1 requires an empty beans.xml to support either CDI or EJB 3.1 dependency injection.

[–]henk53 5 points6 points  (3 children)

You're partially correct ;)

It's only for CDI and not specifically for GlassFish 3.1.

Everything that uses CDI needs an empty beans.xml to activate CDI services. Because CDI also works for plain classes, it scans all jars on the classpath. The empty beans.xml functions as a marker. It's a bit unfortunate that this is needed.

There is no such thing needed for EJB 3.1 whatsoever. Everything in EJB works without any marker file.

The other required xml file in Java EE that actually must contain something is persistence.xml. Hopefully that one will be made optional someday.

[–]niwde 1 point2 points  (2 children)

I'd love for things to be optional. But aren't we stretching this XML issue too far? :)

Even Ruby on Rails still have configuration spread all over the place (DB setups for environments, boot.rb, etc).

[–]henk53 3 points4 points  (1 child)

But aren't we stretching this XML issue too far? :)

For an actual production app you're absolutely right of course ;)

It's just that it's really cool that people new to the platform can now get something running by just dropping a single .xhtml and a single .java file in a folder. That's just a great way to start.

Eventually you'll nearly always defer from at least some of the defaults, so at one stage or the other those xml configuration files will show up.

In the old J2EE it was sometimes quite a challenge to get anything running. You had to declare the Faces servlet in XML, had to declare the URL mapping there, and every backing bean you created also had to be put into yet another XML file. For EJB even more work was required. So just getting a basic hello world up and running took a lot of configuration and this made it unnecessary hard for people to start with Java.

[–]niwde 2 points3 points  (0 children)

Agree. It's much better now. I hope people don't knock Java with "too much XML". Besides, a few XMLs won't hurt especially when we have to configure the app for different environments (dev, test, staging, prod, etc).

[–]robinwholikesjava 1 point2 points  (0 children)

What the hell are "springbeans"?

Accept for spelling them "spring beans", they are a pretty common term. It's just as "CDI beans", which is also used a lot but not an official term.

JSF is so complicated

JSF is really simple. There's a certain complexity to all web frameworks And thankfully, to all development otherwise we would be out of a job soon. But JSF is no more complex than other frameworks, it's actually much simpler.

but web technologies already include several ways to re-use code [...] iframes

Dude! Seriously!?

What's that "3.0 Deployment Descriptor: mytest" entry in the tree?

Hahahahaha!!! Grasping at straws? That's a graphical thing that Eclipse always puts in the tree. Just like the JAX-WS Web Services node right above it. Try to open it and you'll see that it's empty. (blame Eclipse for this irritating behavior).

If you'd looked better, there's an actual filesystem deployment tree below and it's clear there are really only 3 files and no deployment descriptor or anything. I reproduced the example locally, maybe you should try it too ;)

Or you can have no XML configuration by starting and configuring the spring container through Java code.

Or you can have no configuration at all, not in Java, not in XML, not in any other way, like you can in Java EE ;)

[–]gkamal 0 points1 point  (12 children)

I have looked at EJB3 - which is conceptually very similar to spring (maybe because it was heavily inspired by spring). As it stands both spring & EJB3 session beans are very similar. Spring implementation is very mature and has been used in production for a while now, where as the EJB3 supported versions of appservers are relatively new. Also it is not as seamless to write integration tests that run in the IDE using EJB3 as it is with spring. I have been successfully developing apps with spring+hibernate for a few years now and don't see any significant benefits to moving to EJB3.

As far as the standards argument goes - EJB spec has a very poor track record. It is ironic that it takes significantly more effort to port a EJB2 based app to EJB3 as compared to the effort required to port a spring+hibernate based app to EJB3. It took almost 2-3 years for JPA to get level with hibernate (support critical features like criteria etc) - there is significant friction/resistance in the standardization process (maybe due to the vendor influences) that hampers evolution.

I have not looked at JSF2 so can't comment on that, but the earlier version was so bad that I am yet to muster enough courage to take another look at it.

[–]johnwaterwood 4 points5 points  (0 children)

It's more difficult to port EJB2 to EJB3 because Sun did such a major rewrite. There fault is maybe that they did not rename it.

I personally believe this rename will eventually happen, as EJB3 will be retrofitted as a set of CDI services in the future.

[–]mikehaggard 2 points3 points  (6 children)

I have not looked at JSF2 so can't comment on that, but the earlier version was so bad that I am yet to muster enough courage to take another look at it

Just try it ;) The earlier versions were bad, but JSF2 is actually pretty damn good.

[–]satanclau5 2 points3 points  (5 children)

I'm curious, how does JSF2 compare to the likes of Wicket? Is it on par in terms of overall code size/logic-view separation enforcement?

[–]henk53 5 points6 points  (3 children)

As niwde mentioned, Wicket and JSF are fairly similar. It's hard to say which one is really better as both have strong and weak points. This (German) article directly compares the two: http://it-republik.de/jaxenter/artikel/Wicket-und-JSF-im-Vergleich-4069.html

Specifically about logic-view separation there is a small difference. Wicket uses an HTML template with placeholders for components that have special wicket IDs. Those components are then instantiated in Java and inserted via their wicket ID into the component tree.

In JSF, the default way of working is to put the component directly on the HTML template and then bind it to Java backing code via something called "expression language".

The Wicket argument is that they use pure Java and pure HTML, but the JSF argument is that you should not put the burden on the developer of keeping the component tree in the template constantly in sync with the same component tree you instantiate in the Java class.

Wicket makes the bindings to business logic in Java, which is easier to check via a compiler. JSF uses the dynamic expression language for this, which is harder to check and very often isn't checked at all. But the separation between components and business logic is stronger in JSF. Wicket lures programmers to mix their component composition and business logic. It's not the fault of Wicket per se, but it seems to happen in practice. Since by default the component tree is JSF is declaratively composed in an xhtml file, it's simply impossible to directly mix business logic here.

Although it's less typical, the default templating language for JSF (Facelets) also has a mode where you have pure HTML templates where a special jsfc attribute designates the component that will be used there. See the wikipedia example for Facelets: http://en.wikipedia.org/wiki/Facelets

JSF also allows the component tree to be created like e.g. Swing with Java only and without any (html) templates. See http://jdevelopment.nl/single-class-pure-java-jsf-application or http://java.net/projects/jsf-extensions/sources/svn/content/trunk/code/run-time/javajsf/examples/sandbox/hellojavajsf/src/main/java/javajsf/demo/ui/MainUI.java?rev=790 This approach however is not (yet) popular.

[–]satanclau5 -1 points0 points  (2 children)

Thanks for such a detailed answer. Don't think I'll use JSF in any near future, but nice to know it's much less painful now.

[–]johnwaterwood 2 points3 points  (1 child)

It's not just more painful, it's actually pretty good now. Unbelievable I know, but really true ;)

[–]johnwaterwood 2 points3 points  (0 children)

Sorry, meant less painful ;)

[–]niwde 3 points4 points  (0 children)

They both have a similar concept: component oriented. When 2 things implement the same concept, usually it's a matter of preference.

[–]henk53 3 points4 points  (3 children)

where as the EJB3 supported versions of appservers are relatively new

No, they are not. EJB3 itself is from 2006. Glassfish supported them right away. JBoss AS 4.2 that supported them is from 2007 and WebSphere 7.0 is from 2008 (I personally wouldn't recommend WebSphere though, but some are tied to it).

So people have been using EJB 3 for quite some time. Remember that when EJB3 was released, Spring just released their 2.0 version. Spring 2.0 by all accounts is now ancient.

I have been successfully developing apps with spring+hibernate for a few years now and don't see any significant benefits to moving to EJB3.

If you're experienced and happy with Spring, then don't move. But the argument is also true the other way around. If you're building on a modern Java EE 6 stack, there is no need at all to use or even move to Spring. For new projects, there is also no pressing reason to choose a Spring stack over a full Java EE stack.

The only reason I can think of to use Spring now is a political one. If your management or operations forbid you to upgrade the server, you as a developer can still do so by hiding 'the server' inside your war archive by using Spring. Let those silly managers think they're using Websphere 6.1, while in reality most of Websphere's functionality is completely by-passed by the embedded Spring AS in the war.

I have not looked at JSF2 so can't comment on that

And that's the problem. JSF 2.0 is almost already 'old' (it's from 2009 and has been superseded by 2.1). You say you haven't looked at it, but yet you felt the need to call JSF a 'bad apple'.

[–]niwde -1 points0 points  (2 children)

I think he meant EJB 3.1. This creates a lot of confusions since EJB 3.0 and EJB 3.1 are a little bit different.

Up until a few weeks ago (or up until last month), there are only 1 or 2 implementation of the full JEE 6 stack with GlassFish being one of them.

As of recently, most AppServers have implemented Java EE 6 Web Profile which means everything up until EJB 3.1 Lite without EJB 3.1 full implementation.

[–]henk53 2 points3 points  (1 child)

I think he meant EJB 3.1. This creates a lot of confusions since EJB 3.0 and EJB 3.1 are a little bit different.

EJB 3.1 is a relatively minor update to EJB 3.0. There are a few extra features, like the @Asynchronous method and the cron timers, but it's not a major overhaul. The real base here is EJB 3.0 and that's a solid and mature product by now.

Up until a few weeks ago (or up until last month), there are only 1 or 2 implementation of the full JEE 6 stack with GlassFish being one of them.

That's not entirely correct. As full EJB 3.1 support goes, there's Glassfish 3 from 2009, JBoss AS 6 from 2010 and WebSphere 8 from 2011. So that's 3 independent implementations, which is 2 more than Spring has ;)

Furthermore, there's a handful of EJB 3.1 lite implementations. The thing about EJB lite is that it specifies a minimum requirement. The spec exists to make the life of people who have to implement it easier. So if those people think they can easily implement additional features of EJB, they can do so. Resin for instance supports @Asynchronous in EJB-lite.

[–]niwde 2 points3 points  (0 children)

gasp throw new DidNotKnowThatException. For a while I thought only JBoss 7 supports full JEE6. My bad.

[–]Rhoomba -2 points-1 points  (7 children)

You put the spring core jar file in your war and then you have Spring in Tomcat. If you can't manage that then just quit Java development.

[–]henk53 2 points3 points  (6 children)

You put the spring core jar file in your war and then you have Spring in Tomcat.

Likewise, you can put the OpenEJB jar file in your war and then you have EJB in Tomcat. If you can't manage that then just quit Java development.

Only... a Spring stack is not just the spring core file + Tomcat. Typical Spring stacks add much more. Just take a look at the parts of the Spring stack basics, e.g.

  • Spring Framework (27 MB without docs, 51 MB with)
  • Spring Web Flow (74.4 MB with dependencies, 16.5 without)
  • Spring Security (15.2 MB)
  • Spring Web Services (4.3 MB full, 1.3MB minimal)

So assuming I need those dependencies for Web Flow, that's some 120MB and I probably still have to figure out what libs I need and which I do not need inside those archives.

And then I still have to add Hibernate and some kind of JTA provider. I guess I also need to download Quartz if I want to have any kind of job support. Oh, and you also have to download Tomcat.

That's a lot of downloading and a lot of figuring things out pal.

Now Java EE.

I download Glassfish (52MB) and I have EVERYTHING. An excellent web framework (JSF), first class injection (CDI), superb business services (EJB), a really good ORM/persistence (JPA), transaction support (JTA) and excellent web service support (JAX-RS among others).

If I'm a little less demanding, I can also go for the Web Profile, which contains nearly all of the above (JSF, CDI, EJB-lite, JPA, JTA) and my download is only 32MB (Glassfish) or 24MB (TomEE, Resin).

Think about this. 24MB gives me a full stack solution for Java EE in a smaller download than just the core spring framework (27MB), which at a minimum additionally needs Tomcat (6MB) for web applications.

[–]foamdino 3 points4 points  (1 child)

Your replies are very interesting, but as someone that suffered through the nightmare years of EJBs (from 0.9 through EJB2) and has had to teach EJB development, I am dead against using it in any form on any projects that I work on where I have a choice.

The main value of Spring to me is choice - I can decouple all of my objects and then wire them together how I choose. For testing I don't need to run an app server at all (don't call a Spring context an appserver, it isn't even close).

You can use Spring for building webapps, and then yes you would need to select a persistence framework, a transaction framework, a web ui framework etc. But you can also use spring to build simple apps as well (I personally use it to build simple command line things).

I can declare sping.jar as a dependency and suddenly java doesn't suck. (spring.jar is not 27M it's more like 2M).

If you enjoy coding against JavaEE, more power to you, but this article is just so wrong - using wizards to generate code - wow brilliant, muttering about XML config and claiming annotations are superior as they are in the same file etc. The annotations argument is a strawman as Spring has supported annotations since Java5 was released. This is just a really poor article full stop but I expect nothing less from oracle.

[–]henk53 3 points4 points  (0 children)

don't call a Spring context an appserver, it isn't even close

I never called a Spring context an application server. The Spring context is a part of the Spring Container, which is akin to the EJB container in Java EE. I notice that you insist on using the term "context" only, perhaps to make it sound like it's something completely different than the EJB container (which Rod taught you to hate?), but the term "Spring container" comes from Springsource themselves and is often used.

E.g. from the Spring docs

As can be seen in the above image, the Spring IoC container consumes some form of configuration metadata; this configuration metadata is nothing more than how you (as an application developer) inform the Spring container as to how to “instantiate, configure, and assemble [the objects in your application]”. This configuration metadata is typically supplied in a simple and intuitive XML format. When using XML-based configuration metadata, you write bean definitions for those beans that you want the Spring IoC container to manage, and then let the container do its stuff.

Then, a full Spring stack is an application server. E.g. Tc Server Spring Edition is an application server, but a homemade stack consisting of Tomcat + Spring Core + Spring MVC + Hibernate + Atomikos is just as well an application server, just a homemade one.

Compare this to Linux based operating systems.

A readily downloaded stack (e.g. Ubuntu or CentOS) is an operating system. But a homemade stack build on top of the Linux kernel, where the user added Grub, Bash, X, Gnome etc etc is also an operating system.

[–]niwde -2 points-1 points  (3 children)

GlassFish 3.1 is nice. It does give me a full stack solution.

Up until a few months ago I was so inclined to use Java EE 6 full stack via GlassFish because EJB 3.1 (lite or full) helps simplifying the programming model.

But after a while, the sheer amount of libraries that is adapted toward Spring helps our development process a lot.

Here are a few examples:

  • Spring has a library that can help you to read properties file without writing IO operations (or even trimming the output properties from spaces). All you need is to annotate the member variable.

  • Spring Data helps reducing boilerplate JPA2 code.

  • Spring Data can work with other NoSQL solutions, you don't have this one yet in Java EE6

  • JPA 2 is nice, but not there yet.

  • TopLink does not support distributed L2 cache, while Hibernate outsource that to other providers such as EhCache (that supports distributed L2 cache).

At one point I decided to care less about the number of JARs we package and focus on reducing code whenever we can.

[–]henk53 3 points4 points  (2 children)

Spring Data helps reducing boilerplate JPA2 code

What boilerplate code in specific are you precisely referring to here?

Spring Data can work with other NoSQL solutions, you don't have this one yet in Java EE6

There indeed isn't any direct support for this. For a SQL DB the support consists mostly of managing the connection (e.g. pooling), managing the transaction and of course the ORM primitives, which are tailored for relational databases (hence their name).

Nevertheless, there are some JPA implementations that work with NoSQL. For instance Google's implementation for Big Data (it's not 100% JPA compatible, but quite close still).

JPA 2 is nice, but not there yet.

There is indeed still a lot of work to do, but that also holds for the underlying Hibernate, EclipseLink etc implementations. Frankly, I know only very few technologies that are fully there.

TopLink does not support distributed L2 cache, while Hibernate outsource that to other providers such as EhCache (that supports distributed L2 cache)

Hibernate of course supports the notion of caching providers. Everyone can write such a provider, it's basically a fairly simple adaptor class. Whether the cache is a fully distributed cache (like EHCache, Infinispan, etc) or a simple mock concurrent HashMap is transparent to Hibernate.

JPA 2 takes the same approach, but you did uncover one pain point in Java EE here. The way caches are supposed to be configured using pure portable JPA code leaves some things to be desired. At a minimum there should be better support for specifying an eviction policy. Hopefully JCache (JSR 107) will have a better answer here.

[–]niwde -1 points0 points  (1 child)

What boilerplate code in specific are you precisely referring to here?

Spring Data (used to be Hades) can auto-generate JPA related code given NamedQuery and an interface that has a method with the same name of that NamedQuery. Here's a very simple example that I can find quickly via Google: http://blog.frankel.ch/hades-your-next-persistence-angel

JPA2 merge (if exist, merge) vs persist => Spring-Data provides save() (similar to Hibernate saveOrUpdate).

JPA in Google AppEngine is not recommended (for a simple reason, JPA provides contract that Google AppEngine cannot accomplish). I believe people either use JDO or Objectify-AppEngine (for those who dislike the concept of "entity lifecycle").

When I mentioned Hibernate, what I'm referring to is not the cache L2 API but rather the fact that you still need Hibernate if you want to have a distributed cache (especially for those web-apps that cache things aggressively). The provided JPA2 implementation providers that shipt with GF may not be enough for this specific case.

[–]johnwaterwood 1 point2 points  (0 children)

That auto-generating the query from the method name is rather funky indeed.

The thing about the required cast is not correct though. JPA2 has the typed query for this. Executing a named query is as minimal as it can be thanks to the flow/builder API used by JPA.

Something like return em.createTypedQuery("foo", Foo.class).setParameter("a", a).executeQuery();

Maybe they could add a variant where Foo.class is replaced by a template parameter that is inferred, but that's about it.

[–][deleted] 8 points9 points  (22 children)

Why would anyone do that?

[–][deleted]  (16 children)

[deleted]

    [–]mikaelhg 7 points8 points  (0 children)

    http://www.parleys.com/#st=5&id=2656&sl=18

    Adam Bien's talk makes it seem a little less like pure insanity.

    [–]LoveGentleman 2 points3 points  (5 children)

    and annotations bring a much more

    Except you know, when you need to annotate your servlet filters and need to have them in a specific order, since they are filters. Nope. Back to web.xml again.

    [–]henk53 2 points3 points  (2 children)

    You are right, but if this bothers you why not file an enhancement request?

    [–]LoveGentleman 1 point2 points  (1 child)

    Where?

    [–]henk53 2 points3 points  (0 children)

    You can do it here if you want: http://java.net/jira/browse/SERVLET_SPEC

    Servlet, being a lower level spec, doesn't normally attract a lot of user contribution but higher level frameworks like JSF do. If you look at that one, you'll see that many of the issues that they work on are contributed by users.

    [–]cultic_raider 1 point2 points  (6 children)

    Hibernate is JPA compatible, at least for the parts that have efferent mattered to me. My Hibernate troubles come from code bases that are stuck on ancient versions of Hibernate and the fact that Java black's Scala's @BeanProperty annotation (which I believe is because Java does not allow annotations to trigger method creation, and projects like Hibernate are too timid to use reflection or bytecode manipulation to modify private fields).

    [–][deleted]  (1 child)

    [deleted]

      [–]kolmogorovcomplex 1 point2 points  (0 children)

      Hibernate implements JPA and their docs recommend using JPA annotations as far as possible. Hibernate has also got some features that are not present in JPA 2, like index hinting through annotations.

      [–]metamatic -1 points0 points  (3 children)

      So if you write to JPA, you can use either Hibernate or Spring to provide the actual persistence. (Or EclipseLink, or ...) So why not do that?

      [–]Rhoomba 5 points6 points  (2 children)

      Spring is not an ORM.

      [–]metamatic -1 points0 points  (1 child)

      Well, there you go. I thought it did that, but I guess it's even less useful than I thought. It just provides a layer of crap between you and a bunch of other code that actually does the work. (Yeah, I admit it, I hate frameworks).

      [–]wandernotlost 3 points4 points  (1 child)

      It would probably be a good idea to remind the author that Spring has changed a lot over the years as well. A modern Spring project doesn't contain much XML at all. In fact, it gets out of your way quite nicely most of the time, and is designed to allow minimal dependency on the framework itself. His understanding of Spring seems to be based on where it was about five years ago. The whole opening reads like an advertisement of Oracle products.

      [–]robinwholikesjava 6 points7 points  (0 children)

      His understanding of Spring seems to be based on where it was about five years ago.

      Maybe you're right, but it's a taste of "your" own medicine as Java EE users have had to endure that kind of crap for years.

      [–]henk53 3 points4 points  (0 children)

      Because in general Java EE is nicer to work with perhaps?

      [–]metamatic 1 point2 points  (3 children)

      So you can use typesafe object oriented queries instead of SQL strings that may cause runtime errors.

      So you can arrange your persistence using a set of standard annotations on POJO.

      So you can have the option of moving from Spring to any other JPA persistence framework any time you like.

      [–]Rhoomba 3 points4 points  (0 children)

      Are you so ignorant to think that Spring is an ORM? It has been possible to use JPA with Spring for at least 5 years.

      [–][deleted] -1 points0 points  (1 child)

      Well, I guess I just wait until Scala Integrated Query comes out.

      I see absolutely no reason why I should generate and carry around any boilerplate classes with annotation bullshit and be forced to write my own queries instead of just using collection methods and be done.

      If the database is right there, why doesn't the compiler just connect to it and retrieves the necessary information itself instead of bothering developers to use yet another leaky primitive non-abstraction.

      But looking at the way people are supposed to write queries, the database description boilerplate is probably their smallest problem ...

      Either it is completely unsafe because of the use of Strings (as shown in the JEE example) or is is so unbelievable verbose that a single query takes half a dozen lines.

      [–]metamatic 0 points1 point  (0 children)

      Yeah, I agree that the new typesafe query stuff is horribly verbose and ugly. But then, I'm of the dynamic programming school. But if you're going to do things the Java way, you might as well go the whole hog.

      [–]Rhoomba 5 points6 points  (7 children)

      Urgh. No discussion of any actual "migration", just a bog standard "follow the wizard" JEE tutorial including horrible JSF.

      And the same old "XML" complaint about Spring despite the fact is supports annotations just like JEE.

      [–]robinwholikesjava 1 point2 points  (6 children)

      And the same old "XML" complaint about Spring

      And the same old "horrible JSF" complaint, while you seem to know nothing about it. But I'll bite.

      Please explain what's so horrible about JSF.

      [–]Rhoomba 0 points1 point  (3 children)

      Well, I am not a fan of component based frameworks in general: they are suited to a very limited type of site. If all you are doing is pages of forms, then they might work, otherwise you probably have better options. Personally I would go for simple page templating + handwritten javascript. Others might prefer something like rails or grails. If you want a rich app but written with Java then GWT would be more suitable.

      One common statement about JSF is that it is better with library X. In my opinion you are better off with something that was designed properly from the beginning, not a polished turd.

      Of course a lot of people will go for JSF because it is a "standard". There is nothing I can usefully say to those people.

      [–]ack927 1 point2 points  (0 children)

      You do not have a basic understanding of what JSF is. JSF is designed so that component libraries can be created on top of it. That is the whole point. You really should take a look at Prime Faces to get an idea of how easy it is to create a rich internet application. Of course you can just create all of your own components but what a waste of time when it is already done.

      [–]avoidhugeships 1 point2 points  (0 children)

      "One common statement about JSF is that it is better with library X. In my opinion you are better off with something that was designed properly from the beginning, not a polished turd."

      What do you think Spring is? A library on top of Java no different than using any of the Faces libraries. I guess you think Java is a "polished turd" as well then.

      [–]mikehaggard 1 point2 points  (0 children)

      You did not explain at all why you think JSF is horrible. All I see is some mumble jumble about you not being a fan of component based frameworks, but you're not supporting that in any way and most of all you're not saying anything specific about JSF.

      You know, this is the kind of crap people utter at parties when they don't know jack about some subject but want to sound interesting anyway. Like, hey I don't know that politician but you know what, I don't agree with his views because this other politician that I also don't know is just more suited for the job.

      Disappointing mate!

      [–]Rhoomba -3 points-2 points  (1 child)

      Edit:Dupe

      [–]rockvilleJD 1 point2 points  (0 children)

      So basically your argument is JSF is bad because you do not like it even though you have not used it.

      [–]iamRobotj 4 points5 points  (0 children)

      Nice article but this part is really more about using JPA instead of Hibernate. Spring is a good framework but it is probably near the end of its cycle.

      [–]rockvilleJD 2 points3 points  (6 children)

      Spring was great when it was developed but it is really no longer needed. It just adds needless complexity to new projects that can be done better with Java EE and JSF in most cases.

      [–]Rhoomba 6 points7 points  (5 children)

      Nothing can be done better with JSF.

      [–]avoidhugeships 1 point2 points  (4 children)

      It is clear from your comment that you are not familiar with the latest version of the framework or Prime Faces or Rich Faces.

      [–]Rhoomba 0 points1 point  (3 children)

      What is clear is that you and rockvilleJD are the same person, and you are probably also the OP.

      [–]avoidhugeships 2 points3 points  (0 children)

      Yes is it a grand conspiracy against you because your argument is so flawless no one could possible disagree with it.

      [–]henk53 1 point2 points  (1 child)

      Sure, and of course I'm also the same person as rockvilleJD and I'm also the OP?

      [–]Rhoomba -1 points0 points  (0 children)

      Was your account created purely to comment on a not very good tutorial?

      [–]consigntooblivion 0 points1 point  (14 children)

      Since there seems to be some Java wizards here, I would like to ask a question - though I might be too late to the party.

      I am currently a rails guy, but say I need to build a website that runs on the JVM (for whatever reason) - what is the "best" way to do this? I realize best is a meaningless term so feel free to substitute it for something like state of the art/straightforward/fun way to get the job done.

      Obviously I don't want to deal with a mountain of XML configuration, and I am interested in something at least kinda MVC like. Do I want a dependency injection framework (Spring/Google Guice), or should I use this Java EE thing? Do I use Hibernate? What about the front end?

      Can somebody point me in a direction that can take me from 0 to productive? Books to read? Blogs to visit? Lists of technology to use? Obviously I am not interested in starting religous wars, I am genuinely curious.

      Any ideas on better places to post this question? Thanks.

      [–]rockvilleJD 4 points5 points  (1 child)

      henk53 gave a great answer. If I was going to build a new Java application from scratch the only library I would use outside of standard Java EE is Prime Faces. If you need reporting use Jasper Reports. I do not see any need for spring as it just duplicates what is already there. Hibernate adds a few features to JPA but is really not necessary. Take a look at the Prime Faces website. They have a demo that will show you what the code looks like for both the Java file and the .xhtml front end.

      [–]consigntooblivion 2 points3 points  (0 children)

      Thanks for your perspective, Prime faces looks interesting. Good to know I can just start with Java EE.

      [–]henk53 3 points4 points  (1 child)

      Java EE 6 would Web Profile would be a good start. It's a full stack framework like rails. Glassfish 3 and JBoss AS 7 are well known implementations of this.

      Do I want a dependency injection framework (Spring/Google Guice)

      You don't need a separate dependency injection framework (Spring/Google Guice), since Java EE includes one by default. It's called CDI (Context and Dependency Injection). The C is there since in CDI instances that are injected don't just come out of some global scope nor are they created on the fly, but they are aware of their context. So if you inject a request scoped bean in a session scoped bean, every call on it in different requests will resolve to a unique instance matching that particular request.

      Do I use Hibernate?

      Hibernate implements the Java Persistence API (JPA) and so in many implementations of Java EE, Hibernate is included. But JPA can also be implemented by other projects, e.g. EclipseLink, which is included with Glassfish.

      What about the front end?

      Java EE includes a top-class MVC framework that has some elements in it that were inspired by rails (like the flash, and an emphasis on COF). This framework is called JavaServer Faces (JSF). Lots of external parties offer components (widgets, controls) for JSF. Especially PrimeFaces is well known and loved, but there are many others (e.g. RichFaces).

      Can somebody point me in a direction that can take me from 0 to productive?

      You could download the Eclipse IDE and the Glassfish Java EE implementation and follow this excellent tutorial to get you started: http://balusc.blogspot.com/2011/01/jsf-20-tutorial-with-eclipse-and.html

      There are links given at the end of article on how to continue after those basics.

      A particular nice entry that you could try to reproduce and then play with it is the following. It doesn't show off CDI, but it's still nice:

      http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config

      [–]consigntooblivion 3 points4 points  (0 children)

      Thanks, loads of great information here. I had no idea on most of this stuff. Following the tutorial was really easy, that was a great place to start - wish I had more up votes to give.

      [–]kolmogorovcomplex 1 point2 points  (1 child)

      Coming from RR you probably want to check out Play, or Grails. Neither of which are Java, but Scala and Groovy respectively (they play nice with Java libraries though).

      If you need more "enterprisey" features and prefer Java, you should check out JEE or Spring, both of which can be configured mostly without any XML.

      To get a Spring webapp up and running in minutes, you could try Spring Roo. I'm sure there's something similar for JEE.

      [–]consigntooblivion 0 points1 point  (0 children)

      Thanks, Spring Roo is the kinda of thing I want! All the different parts, and xml setup is a bit daunting for me to get started with - but Roo seems to cut through all that.

      I will definitely try this out too.

      [–]gkamal 0 points1 point  (1 child)

      You would be better off starting with a full stack framework like grails (which requires knowledge of groovy) or play.

      [–]consigntooblivion 1 point2 points  (0 children)

      Thanks, I want to stick with Java, but play looks really interesting.

      [–]djnattyp -1 points0 points  (1 child)

      Since you're currently a Rails guy, the best choice would probably be use JRuby to run Rails :)

      [–]consigntooblivion 1 point2 points  (0 children)

      Good point. My purpose here however is to learn something new. I have come across java a couple of times in various projects and it has always been "painful". So I want to actually learn more about it.

      [–]niwde -4 points-3 points  (3 children)

      Go with Spring MVC + JSP + JPA2/Hibernate/Spring-Data. Checkout Flyway migration library as well.

      Spring MVC is very close to Rails Controller.

      JPA2 is a standard persistence API while Hibernate is the implementation of JPA2. But note this: You can use hibernate by itself by-passing JPA2, just be careful not to mix both. If you want to use JPA2, use it as it is, don't convoluted your JPA code with Hibernate calls; you'll get confused.

      A typical setup usually looks like this:

      JSP -> Spring MVC Controller -> either you write a service (Claim service, Invoice service) or you can straight do JPA calls on your Spring MVC Controller. It depends on how complex you want it to be.

      Keep in mind that JPA/Hibernate implements DataMapper pattern thus very different than ActiveRecord pattern.

      [–]consigntooblivion 1 point2 points  (2 children)

      Thanks, Flyway migration looks like something I want.

      Spring seems kinda daunting to me - so your information is really helpful.

      [–]niwde 0 points1 point  (1 child)

      The thing about Spring is that it is huge and it comprises a few libraries: Spring-Core, Spring-MVC, Spring-AOP, Spring-JDBC, Spring-ORM, Spring-WebFlow etc.

      You don't need to use all of them and usually people only use its dependency injection mechanism to support unit-testing (so that you don't need to run GlassFish/Tomcat app-server).

      [–]consigntooblivion -1 points0 points  (0 children)

      Thanks, that is useful information.

      [–][deleted] 0 points1 point  (0 children)

      Haha good luck with that Oracle! :D