
Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012 - markokocic
http://www.javacodegeeks.com/2012/03/why-i-will-use-java-ee-instead-of.html
======
CodeMage
The article is almost completely devoid of useful content. Basically the only
useful argument is: JEE 6 has most of the stuff Spring has, it's "light"
(lighter than J2EE) and, unlike Spring, it's a standard with several reference
implementations.

While the argument itself is worthy of discussion, there was no need to
package it inside an article full of fluff.

The author claims that she hopes to be neutral, but completely fails to do so
when it comes to comparison of Spring and JEE: she lists advantages of JEE and
then those of Spring, but makes sure that each of the Spring advantages listed
is accompanied by a "BUT", which boils down to either "JEE has it too" or "JEE
doesn't have it, but you probably won't need it".

Yes, I know she said beforehand that she would explain why differences between
Spring and JEE lead her to JEE, but the way she did it robs her of neutrality
she claims to have. And it's not just the form I'm talking about, it's the
substance, too. If all of your reasons to lean towards JEE boil down to "well,
it has all that I need that Spring has and I personally don't care about the
stuff it doesn't have", you're not really contributing anything.

~~~
astrodust
Most Java programmers wouldn't know "light" if it fell on them and pinned them
to the ground.

~~~
UK-AL
As a java programmer I get offended by this. I was taught programming on
scheme, I use django for quick apps, i know a variety programming paradigms
but there is no one best tool to rule them all. Different tools are good for
different jobs.

For example scala programmers completely ignore backwards compatibility
problems they have had in the past. Such a thing would unimaginable for a
large app.

~~~
herval
I like it how you get offended by a generalization, then go on and throw
another one at a different "faction" :)

------
edwinnathaniel
We recently delivered a big integration project using the best of both worlds.

1) Spring Portlet MVC - cause we have to deal with Portlet (don't ask)

2) JAX-RS client-side - Portlet talks to GlassFish via JAX-RS

3) JAX-RS server-side - GlassFish RESTful (this is probably one of the key
feature for using JavaEE 6, a simple, straightforward, productive way to
create APIs that can return XML or JSON or ATOM or ALL of them easily via
annotation). JAX-RS is very similar to Sinatra.

4) JAX-WS client-side - to communicate with 3rd-party systems

5) JAX-WS server-side - to provide services for 3rd-party systems

6) Spring-Data - to reduce writing boilerplate JPA 2.x code (the way Spring
Data works is as simple as writing an interface method where the method has
the same name to the NamedQuery and Spring will automagically inject bytecode)

7) Spring library to read properties file - no need to write the actual
implementation of a class that reads a property file and deal with IO
exception abd opening/closing files try-catch-finally. Provide an interface
and annotate the interface, set up minimal config and you're done.

8) Apache Derby to test the persistence layer for integration testing

9) Spring Web Test module - this provides HTTP Request/Response mock object so
you don't have to construct your own

Other libraries:

10) FlyWay - database migration library that integrates nicely with Spring as
well. Flyway is executed when you deploy your EAR/WAR to your App Server
container.

11) GSON - Java to JSON object converter written by someone from Google. We
send JSON from our Portlet MVC to the front-end that is of a mix between JSP
(5-10%) and heavy JS usage.

12) Dozer - Object to Object mapping, very useful if you have to deal with
3rd-party systems that have a subset or superset of your internal/local domain
model.

13) Maven - we can build for multiple environment (DEV, UAT, PROD, STAGE,
etc), it's easy.

We are quite satisfied with the set-up and I have to say that if you come from
Rails background, the only part of the stack that would make you a bit unhappy
is the database ORM since ActiveRecord is probably nicer compare to the JPA
2.x/Hibernate/Spring-Data.

We're not using EJB yet but we may use it in the future if we have to use
queue via JMS as well. To my knowledge the latest EJB (3.1) helps you a lot to
deal with transactional multi-steps operations that include persistence
operations and JMS operations on one execution path.

I'd say the code that we have to write is almost as short as Rails when it
comes to the business logic part.

Deployment was straight forward: package it up as WAR (or EAR) and deploy it
to GlassFish.

The part that we're lacking right now is the front-end. Even though we're not
using JS _that_ heavy, we are moving toward that direction and eventually we
have to clean it up and start using best-practices (Backbone.js,
Underscore.js, and a few other things).

------
vetler
JEE 6 is a huge leap forward compared to how J2EE used to be. However, there
are a few problems.

First of all, JSF is the most horrible framework for creating web applications
that I've ever used. Its intention is to make web development easier, but what
you get is a huge mess of HTML and JavaScript that introduces a lot of new
problems. Escpecially since it gives you the impression that you don't need to
know HTML and JavaScript to work with it.

EJBs are a lot easier, and as long as you don't access them remotely, you
don't need interfaces or XML files. If you put them remotely, you need both.
With injection you don't need to look up EJBs manually, except if you put them
remotely - because if the reference to the remote EJB is invalidated (i.e. if
it's accessed while the remote server is down), you'll need to look it up
manually again.

As long as you choose something other than JSF, JEE 6 is fine.

Of course, then there's the application servers. I've only tried Glassfish
(for a while it was the only fully certified JEE 6 app server), but it had a
few problems - I heard one of the latest versions had a GZip filter that would
have spinning threads taking 100% CPU.

JEE has come a long way, but I'll probably choose Spring for my next Java
project.

~~~
edwinnathaniel
JSF2 has definitely improved compare to the previous version but I suppose JSF
(1/2) is more akin of ASP.NET (component oriented) which might put off a large
number of developers who prefer simple templating with pure JS.

------
lebski88
I'm exceeding unconvinced by this article. His plus points for JEE were really
stretching:

\- Sustainability - do we really think Spring is going to die?

\- Light weight testing is possible - so JEE has caught up with spring...

\- Convention over configuration - like spring.

\- Multiple providers - OK that's a potential benefit but I'm not seeing the
realisation of it yet. It could also mean that different providers have
different bugs.

From my personal investigations Spring offers many advantages. In some places
JEE has matched them in others it's still behind. So I would ask myself do I
want to go with the framework that's driving the advancement, or the framework
that is playing catchup? Also these days Spring is the standard.

------
jfager
Alternate title: Why I will stab my eye out with a fork instead of running a
cheese grater over my knuckles.

~~~
moondowner
Definitely. I'm perfectly happy with Spring. A developer can create the most
lightweight web application with the most manageable code with Spring.

~~~
Torn
Have you tried Play (playframework.org) yet?

~~~
rufugee
I have high hopes that Play will become the defacto "pragmatic"
java/scala(/kotlin, when it's finally ready) framework. Play rocks.

~~~
eropple
I would dearly like to use Play, but I find it really uncomfortable (and not
because I'm some stuck-in-my-ways Java developer). Play's heavy abuse of
statics is a real problem from my perspective, in large part because it's
extremely painful to write inheritance-based code; I realize it helps the
simpler use case but I find that I don't regularly write to the simpler use
case.

I've gone back to Servlets+Guice+Velocity because it's easier for me to write
expressive code.

------
robfig
Why would someone use J2EE or Spring over the Play Framework (which we use at
work for our "mission critical enterprise applications")?

Basically, what enterprise features am I missing out on by not using one of
them?

~~~
UK-AL
Java EE is a big hammer, it's got everything you could possibly ask for. You
used to pay for this by requiring huge config files. Ejbs for example allow
access from remote servers to objects as if they were local Objects. This can
be used to separate out general application logic from the web, native
application, web service interfaces which can be run on there own dedicated
servers all communicating with the backend transparently via ejb. Any
operations in a ejb are automatically transaction with the database. Ejbs used
to be a configuration nightmare though, but not anymore.

Java play is the get it done platform.

They both have their uses.

------
livando
With this article I was really hoping for some counter points of how JEE is
doing some new and exciting things. Unfortunately, it looks like the only
innovation was to throw some of the dead weight off the back of the truck. I
can understand how corporate developers (i.e. can't use open source and it
needs a support plan) would be happy about the lighter alternative approaches.
I just don't see how given the whole technical landscape, that JEE is still a
viable front runner.

~~~
UK-AL
What? Jee is a open standard, there are open source and closed source
implementations of that standard.... The idea being applications are portable
between different vendors. If anything it's even more "open source" than most
open source frameworks.

------
juliano_q
This article only reinforced my conviction to use Spring and not JEE. It is
possible to test on JEE? It is "light"? It have convention over configuration?
Well, Spring has it for almost a decade, is trivial do deploy on any server
and have much more powerful libraries. Furthermore, JSF is horrible.

------
mark_l_watson
I used Java EE 6 a lot last year when I was helping a friend's company. Yes,
it is a major improvement over JavaEE, especially JPA 2. I agree with the
author of the article that Java EE 6 has a place for large mission critical
applications. That said, I have had a good experience with two (admittedly
small, and medium sized) Clojure + Compojure + Noir web apps: very stable, no
apparent memory leaks so far, "just runs forever", etc.

Java EE 6 is a great skill to have, job wise, but it is more fun using agile
platforms.

------
UK-AL
JEE has improved, and I'm considering it over spring. Everything's annotation
based compared to what jee used to be. Just use an annotation for a ejb, a
persistence context, to get request any object you require via DI like a user
service object for handling user profiles. Add a annotation and you've got
your self a web service that implements rest etc

------
thebluesky
Friends don't let friends use either Spring or Java EE.

~~~
Sandman
You've already expressed your disdain for both Spring and Java EE in several
comments. However, I haven't noticed that you provided any arguments on why
you think both of these solutions are bad. I'd be interested in hearing them.

~~~
codemonkeyland
I think he's simply stating what has made many Java programmers very cynical
about frameworks such as these. Java EE layers abstraction on top of
abstraction. App servers like WebSphere use a ton of memory before you've even
deployed your app to the server and they charge you an arm and a leg (yes I
know glassfish and jboss are free). Java code is verbose and ill-suited to
crafting systems which generate html. The Java enterprise camp was championing
the idea that web applications should have JSP talking to session beans, which
talk to entity beans which then talks to your actual data store. By the time
you've coded it all up you realise that it's slow before you've even added any
business logic. Things have improved since then, but they lost my trust a long
time ago. Spring seems to love having programmers take java source and
translating it into XML so it's much more verbose than java (quite a feat in
itself) and hides some of the most critical code from the IDE. The "benefits"
provided by such approaches are marginal at best. The ironic part... I'm a
huge fan of Java the platform, just despise the culture of bloatware which has
sprung up around it. The world is moving on to lightweight solutions which
don't require app servers which generate stack traces so long that they span 3
screens.

------
eccp
Use none of them, try Grails or JRuby. Really.

------
francoisdevlin
And this is why I use noir.

------
shareme
Now you know why I do not write articles for javacodegeeks..

This article is devoid of any dev value

