Why Java EE?

[Kevin Wong]

I recently listened to a presentation by Gavin King on Seam. He
describes Seam and, among other things, argues the superiority of its
approach over that of light containers such as Spring.

Now, I've been using Spring for the last 2 years and am writing, by
all measures, the best code of my career: highly covered, loosely
coupled, low CRAPload.

So, my question is: Why do I need Java EE? What does it give me that
Spring cannot? These questions are not rhetorical and I have an open
mind on this. I just don't have the knowledge or experience to answer
these myself. BTW, I'm talking about the full-on Java EE requiring a
Java EE applicaiton server, not the more ubiquitous parts of the spec
like servlets that can be handled with a web server like Tomcat/
Jetty. Also, I know that I can use Spring and Java EE together, but
my question is: Why bother?

Incidentally, here are some reasons why I am averse to using Java EE
(mostly EJB3):
- Added deployment complexity of installing/maintaining an application
server
- Requires app redeploy to test code changes (this is a big one for
me)
- Marries me to an API. The "not standards-based" argument is
commonly levied against Spring, but I never did buy that. Just
because an API is a standard doesn't make the lock-in entailed with
its use any less real. From a code maintenance perspective, the
ability to swap out vendor implementations buys me nothing. Given the
choice between locking-in to a proprietary or standard API, of course
the prudent choice is the latter. But Spring apps are dependent only
on the functionality that it provides, not on any API. So, the choice
here is between locking-in to a standard or using Spring and locking-
in to nothing.

Replies based on practical experience would be much appreciated.

[Christian Catchpole]

>From my experience EE was always chosen by non or not so technical
managment just because "that's what enterprise uses". Sun told us
to. Now without arguing the specific pros and cons of EE, in the
early days there were perhaps less options that gave you the same
result. But at the same time the original EE implementations were
especially bad. I think it also create apps that were totally over
engineered. Imposing clustering and big picture requirements which
just didn't work and caused projects to fail. Clustering is a good
thing, but you have to do it right or you cant do it at all. Database
manufacturers had been working on it for a long time before Java came
along it can never be totally solved. But I digress... :) I was
always apposed (and still am) apposed to the heavy weight approach of
EE.

I wrote a doclet recently, which I am very proud of - I think it's way
cool in it's practicle simplicity...

http://catchpole.net/bonsaidoc.html

Something which occured to me in the process. The simple power of
interfaces is one of Javas strong points. Its as though Sun didn't
know what they had in their hands, using things such as:
- Static method entry point for Doclets
- non-interfaced "secret squirred" methods for original
"externalizible" interface.
- Using class extension rather than interfaces for many EE classes,
forcing an implementation and compile time dependencies... but maybe
that was their point. :)

[Brice]

On Nov 12, 2:19 pm, Kevin Wong <kevin.peter.w...@gmail.com> wrote:
> I recently listened to a presentation by Gavin King on Seam. He
> describes Seam and, among other things, argues the superiority of its
> approach over that of light containers such as Spring.

I think Seam is meant to be a full-stack, one-stop shop, much like
Rails - and if that's what you need, great. Its not necessarily the
flexibility of Spring to be anything and everything, but that's OK if
that's not what you need.

>
> Now, I've been using Spring for the last 2 years and am writing, by
> all measures, the best code of my career: highly covered, loosely
> coupled, low CRAPload.
>
> So, my question is: Why do I need Java EE? What does it give me that
> Spring cannot?

Chances are, if you're asking, you probably don't need the additional
things EE provides, that would be my first thought. That said, doing
things like managing distributed transactions isn't trivial and its
something that EE provides (or is supposed, some implementations are
better than others). So, if you need to use JMS (receive a message)
then do some work (both locally and maybe with a remote system, either
via web service or say an RMI call) and then send another message or
two out on JMS - and you want all that to either succeed or fail
together, with the common ACID properties we all know and love - then
you'll probably want something like EE to manage that for you. Of
course, there are other things, as well, but again - if you're asking,
you probably don't need it.

> These questions are not rhetorical and I have an open
> mind on this. I just don't have the knowledge or experience to answer
> these myself. BTW, I'm talking about the full-on Java EE requiring a
> Java EE applicaiton server, not the more ubiquitous parts of the spec
> like servlets that can be handled with a web server like Tomcat/
> Jetty. Also, I know that I can use Spring and Java EE together, but
> my question is: Why bother?
>
> Incidentally, here are some reasons why I am averse to using Java EE
> (mostly EJB3):
> - Added deployment complexity of installing/maintaining an application
> server

eh, not really that big a deal. Sure, if you're using Websphere, its a
bit more of a pain, but JBoss, for example, is no more a pain to setup/
maintain/install in its "standard" configurations than Tomcat/Jetty/
Resin.

> - Requires app redeploy to test code changes (this is a big one for
> me)

Nope. We use "exploded" .ear deploys all the time that allow us to
update JSPs, etc. without having to redeploy. Using an IDE like
Eclipse, MyEclipse, etc. (probably Netbeans & IntelliJ, too) that is
"attached" to the VM running your container (this goes for Tomcat or
EE containers) allows you to hot-swap in code changes as well, as long
as the VM itself likes what you're swapping in (this isn't an EE
limitation, per se).

> - Marries me to an API. The "not standards-based" argument is

eh, ok - maybe. But, really - you want to keep your "core" code as
POJOs and just throw in a quick layer here or there when you need to
do something special. Many EE things are just annotations now, or
going that way - so that's fairly unobtrusive (not that I'm ra-ra-ing
for EE). Also, advanced things in Spring aren't any less "married" to
Spring's APIs - if you start doing AOP with Spring & AspectJ, you'll
be writing your advice to those APIs, which won't be compatible with
other AOP implementations.

This is what I've found - we actually use Spring in an EE container
(JBoss) and I've started looking at Seam and I've done a project with
Hibernate/EJB3 and GWT, so I guess I've done a bit of everything
you've mentioned. I think the principles you've learned that's lead to
your writing less CRAPful code will carry through to anything else you
want to do. I'm constantly looking for ways I can inject dependencies,
wrap things in interceptors, etc. - irrespective of the underlying
implementations I'm using.

Hope this helps!

[Kevin Wong]

Thanks. This was very helpful.

> Chances are, if you're asking, you probably don't need the additional
> things EE provides, that would be my first thought. That said, doing
> things like managing distributed transactions isn't trivial and its
> something that EE provides (or is supposed, some implementations are
> better than others). So, if you need to use JMS (receive a message)
> then do some work (both locally and maybe with a remote system, either
> via web service or say an RMI call) and then send another message or
> two out on JMS - and you want all that to either succeed or fail
> together, with the common ACID properties we all know and love - then
> you'll probably want something like EE to manage that for you. Of
> course, there are other things, as well, but again - if you're asking,
> you probably don't need it.

There seem to be standalone JTA and JMS implementations that can be
easily integrated with Spring without the need for a JEE server
(http://www.javaworld.com/javaworld/jw-04-2007/jw-04-xa.html?fsrc=rss-
index). I have no need for distributed transactions or JMS currently,
but might in the future.

[Dario Laverde]

I agree with what Brice states, especially since you can now mix and
match running Spring in JEE and vice versa (e.g. with Pitchfork), so
yes you can apply the principles and practices with either and it
really comes down to which style you prefer rather than just technical
merits.

That being said, you have to keep the historical context and business
objectives of the guiding companies in mind, Spring is a direct result
of J2EE/EJB 2.x's failings but now we have the EJB 3 and related
standards. I know you prefer not to hear the "not standards-based"
argument, but even Spring 2.5 is moving towards compatibility with the
new annotations. Standards are a good thing and Spring shouldn't
really be pit against JEE in a feature by feature war, they can
interoperate using standards.

On Nov 13, 12:23 pm, Kevin Wong <kevin.peter.w...@gmail.com> wrote:
> There seem to be standalone JTA and JMS implementations that can be
> easily integrated with Spring without the need for a JEE server
> (http://www.javaworld.com/javaworld/jw-04-2007/jw-04-xa.html?fsrc=rss-
> index). I have no need for distributed transactions or JMS currently,
> but might in the future.

OpenEJB 3 can be embedded in Tomcat and doesn't require a JEE server
(it uses OpenJPA and ActiveMQ for JMS) and as mentioned earlier you
can use a collapsed ear format "hot-swap in code changes" and avoid
deployment issues.

regards,
Dario Laverde
http://javanotebook.com

[Brice]

Certainly, there's a number of standalone things that can provide the
things that an EE container provides, at least to some degree. Once
you need those various things to work in harmony, though, you may find
that having an EE container where a vendor has actually tested all the
pieces working together, is worth the additional effort of using a
container.

The nice thing is that you can continue not using a container and if
you ever get to the point where you want to try and see if a container
simplifies things, then your app (by virtue of using Spring) should be
fairly easy to bring up in a decent EE container like JBoss,
Glassfish, WebSphere, etc.

For the record, there's a great many other things that these
containers provide, that aren't necessarily part of the EE spec, but
that these vendors have delivered to meet their customers needs.
Things like clustering, distributed caches, transactional caches, high
availability singletons (singleton running in a cluster w/ failover),
session replication in a cluster, session replication in a subset of a
cluster (if you run big clusters), web service abstractions, etc.
Taken individually, some of these things can also be run independently
(and many, if not most, started off that way) - but again, if you need
these things to work in harmony, then do you want to be on the hook
for that?

The application I'm working on now will run in a JBoss cluster, with
session replication (using JGroups), caching with OSCache, HA
singleton running certain "singleton" threads, XA transactions with WS-
TX and JTA (2-phase commit over a series of web service invocations)
as well as receiving and sending messages via JMS over IBM MQ Series
and accessing and storing data in Oracle and DB2. Its a fairly big
applications and I for one am happy that I don't have to worry about
these things "just working" (mostly because there's another group at
this company that does - and they can lean on JBoss/Redhat).

So, in short, one of the differences may just be - are you in an
"enterprise" where your deployment platform needs to meet the needs of
hundreds of applications using oodles of various legacy tech, or not?
Unfortunately Sun has smeared the line for EE and made it seem that if
you're writing web-apps, you need EE - that's definitely not the case.

Cheers,
Brice

[Peter Becker]

My experience is that mixing JEE products from different vendors can
be a pain -- things don't necessarily work well together and of course
everyone involved says it's not their fault.

But then: things should be better if you are using OSS (different
culture and you can debug and fix things yourself). And my main
experience was mixing BEA WebLogic with IBM's WebSphere MQ, which is
probably on the bad end of the spectrum of things to do -- but it is
what happens if your client has certain types of product policies. It
worked, but somehow we as a project had to learn quite a few skills
that I'd consider admin/product support.

So I'd personally tend towards integrated solutions. That's of course
only a tendency and there are many other factors to consider -- just
don't forget to ask the question who is going to support problems with
the platform you come up with in the end. That answer can be "we
will", but then make sure you budget for that. Unfortunately it is not
necessarily as easy as just plugging things together.

Cheers,
Peter

[Brice]

And just to play devil's advocate to Peter (and myself) - it isn't a
slam-dunk if you use an "integrated" EE suite, either. We've had our
share of issues w/ JBoss + other JBoss "gems" as well as IBM Websphere
+ other IBM products. The difference is that if *you* pick the mix,
*you* get to figure out what's the problem. If you get a package, then
you can lean on your vendor to help out.

Of course, this supposes that you're paying for support (though even
free support is often better than figuring it out yourself). The
company I'm at right now has a JBoss (RedHat) support contract (and an
IBM one), so when we find problems, we have someone to lean on ;-) We
don't have a Spring support contract (would that be Interface21? do
they even do open-ended support? dunno) - but we still manage to use
Spring quite effectively.

Cheers,
Brice

On Nov 13, 5:42 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
> My experience is that mixing JEE products from different vendors can
> be a pain -- things don't necessarily work well together and of course
> everyone involved says it's not their fault.
>
> But then: things should be better if you are using OSS (different
> culture and you can debug and fix things yourself). And my main
> experience was mixing BEA WebLogic with IBM's WebSphere MQ, which is
> probably on the bad end of the spectrum of things to do -- but it is
> what happens if your client has certain types of product policies. It
> worked, but somehow we as a project had to learn quite a few skills
> that I'd consider admin/product support.
>
> So I'd personally tend towards integrated solutions. That's of course
> only a tendency and there are many other factors to consider -- just
> don't forget to ask the question who is going to support problems with
> the platform you come up with in the end. That answer can be "we
> will", but then make sure you budget for that. Unfortunately it is not
> necessarily as easy as just plugging things together.
>
> Cheers,
> Peter
>

[Kevin Wong]

All these multi-vendor integration problems kinda makes you wonder
what the point is in having standards.

[Casper Bang]

On Nov 14, 5:21 pm, Kevin Wong <kevin.peter.w...@gmail.com> wrote:
> All these multi-vendor integration problems kinda makes you wonder
> what the point is in having standards.

The whole multi-tier vendor-agnostic thing to me is an example of
something that looks good on paper, but in practice rarely works out
for most. It certainly didn't for us when juggling Oracle ADF for a
few years.
Having a thin/simple solution might bind your more to one vendor, but
chances are productivity in this category is so much more powerful
that it would not really cost more to move to another and rewrite some
stuff compared to dealing with a chaotic database/ORM/persistancy/
validation/presentation/server/configuration stack. This can be
witnessed in several places, perhaps most noticably in RoR and .NET
3.5 where i.e. a database is just a dumb data container and nothing
more.

/Casper

[Peter Becker]

I think there are two main areas where standards can fail:

(a) the standard itself is not that good, e.g. forgets some scenarios
or is inspecific or even inconsistent -- AFAIK early versions of
Bluetooth fell into that category
(b) they are not enforced properly

I think point (b) is quite interesting. In theory consumer power could
enforce a standard, but it's like assuming voters cast sensible votes
-- sounds good in theory, but in practice other effects can easily
override the sensible behaviour. As example: SQL was a standard as
long as NIST tested it (and no US government agency bought anything
not succeeding the test), it broke apart when NIST stopped the
testing.

I think Sun is doing the right thing with the TCKs and certification
programs. You can still get something that is kind of JEE but not 100%
-- it just won't be certified. If you want to play the safe(r) game,
you take only certified components.

Coming back to JEE: I must admit that I never bothered to fully read
the JEE spec or actually really check who's certified and who's not (I
think that TCK is only a recent thing and I haven't been in any
position to chose a JEE platform lately). But the issues I remember
were all on a level that I strongly suspect will not be covered in the
specs: the administration side. Basic things like the web.xml might be
defined, but all the other configuation issues are always
vendor-specific and I suspect that they always will be -- a lot of
these things can be OS-specific, too. We have had issues on the Java
API levels, but that's the stuff you can easily file as a but
somewhere. The problem is the stuff everyone declares to be someone
else's problem, which means in the end it is yours since you are the
only one who cares. If it is covered in the spec it is easy to tell
who's fault it is if it doesn't work the way it should.

Peter

[vineetb]

Its funny how Java EE 6 (http://jcp.org/en/jsr/detail?id=313) is an
effort to standardize enterprise application development. Its got
years of man hours contributions from members such as BEA, IBM,
Oracle, JBoss, Apache.
OTOH, Spring is not standards based and created *mostly* (http://
www.ohloh.net/projects/41/analyses/latest/contributors) by
Interface21.

But now, Interface21 is also started getting involved in Java EE 6
(http://blog.interface21.com/main/2007/09/30/our-approach-to-the-jcp/)

So even though now its a question of Spring vs Java EE, in 3 years
that will become irrelevant. Something similar to the Hibernate vs JPA
argument. In future, a specific profile of Java EE 6 will be a
lightweight IoC framework (thanks to Spring)

Like many of you have pointed out - Innovation happens first.
Successful proven ideas are made standards. Not the other way around.

To answer your question *today* - you don't need Java EE if you get
all the features from Spring. The answer will obviously be different
in 2-3 years.

- vineet

[Kevin Wong]

I hope you're right, but will vendors allow JEE to become a
lightweight container if it means the death of the application
server? Gavin King, who speaks for one such vendor, JBoss, doesn't
even agree that IoC/DI is the proper way to architect enterprise
applications.

On Nov 16, 1:31 pm, vineetb <vineet.vine...@gmail.com> wrote:
> Its funny how Java EE 6 (http://jcp.org/en/jsr/detail?id=313) is an
> effort to standardize enterprise application development. Its got
> years of man hours contributions from members such as BEA, IBM,
> Oracle, JBoss, Apache.

> OTOH, Spring is not standards based and created *mostly* (http://www.ohloh.net/projects/41/analyses/latest/contributors) by

[Rick]

NB: for the purpose of my reply, I am going to assume that we are
talking about Java EE 5, and _not_ J2EE, even though that distinction
is not clear in some of the other replies.

> So, my question is: Why do I need Java EE? What does it give me that
> Spring cannot?

Java EE 5 is a huge step in the right direction: getting rid of XML
configuration.

My complaints with Spring are along the lines of Transaction and
Database support being _very_ fiddly.

Also, Spring is broken for refactoring.
E.g. I have a Class A which I'm injecting in one place, and I extract
some method signatures into Interface B, which Class A implements
(without changing _anything_ else in A), but now _everywhere_ that I
inject A is broken. I think it has something to do with the way
Spring aggressively proxies interfaces?

For someone like me that likes to operate at a higher level of
abstraction, and refine the design, that makes Spring frustrating.

I think that later versions of Spring allow you to use @Annotations,
so Spring will adapt and improve, rather than staying in one place and
stagnating.

As for inversion of control, I don't think that it is such an amazing
thing as to justify an entire framework. I do like some of the stuff
that comes with the grab bag of stuff. Their basic web framework was
pretty good (Spring MVC), but there was another web framework which
was horribly broken when I looked at it (i.e. the examples didn't work
as advertised out of the box), which is good for those who require
their web framework to be enormously complex for no good reason. :D

I think GWT is better than Spring MVC, passing a java object back to
the client side is just too cool. But all the freebies I get with
Spring MVC are way better than any of the other 'server side'
frameworks I've seen.

One of the things I see a lot of is Hibernate still being a required
skill on projects. It doesn't seem to have sunken in that:
EJB3 > Hibernate

One of the great things with Netbeans and Java EE 5 was being able to
abstract away from my persistence layer. Yes, I can use Hibernate,
but I don't have to get my hands dirty with the Hibernate XML files
(because if you do, you are in for a world of pain). It may generate
the Hibernate XML files somewhere behind the scenes, but as they say
out of sight, out of mind.

Also, Java EE 5 is a nice conceptual fit with JAX-WS, since they are
both @Annotation based frameworks. I think JAX-WS is one of the more
amazing hidden secrets of Web Services. I guess because the SOA
pushers would find their business collapsing if Web Services became
easy, and JAX-WS makes them incredibly easy indeed.

On reflection, taking out all the SOA consultants and shooting them
would be an important next step for Java. It seems they collectively
have their feet jammed firmly on the brakes of Java progress, since
they have an agenda of making life extremely difficult for developers,
so that they can push their products and services. Whereas removing
the SOA bus typically allows you to make _all_ the WS/SOA pain go away.

[Christian Catchpole]

On Nov 18, 5:04 pm, Rick <rickcar...@gmail.com> wrote:
> On reflection, taking out all the SOA consultants and shooting them
> would be an important next step for Java. It seems they collectively
> have their feet jammed firmly on the brakes of Java progress, since
> they have an agenda of making life extremely difficult for developers,
> so that they can push their products and services. Whereas removing
> the SOA bus typically allows you to make _all_ the WS/SOA pain go away.

I think historically there are these waves of theories and
technologies that look good on paper and have good intentions but are
undone by reality and soon become anti-patterns. Im proud to be the
stick in the mud who says "well that aint going to work" while
everyone else is calling me a flat-earther. Perhaps thats why I
havn't done so well as a consultant. :)

[Kevin Wong]

> Also, Spring is broken for refactoring.
> E.g. I have a Class A which I'm injecting in one place, and I extract
> some method signatures into Interface B, which Class A implements
> (without changing _anything_ else in A), but now _everywhere_ that I
> inject A is broken. I think it has something to do with the way
> Spring aggressively proxies interfaces?

True, but a good IDE (e.g., Eclipse) will refactor fully qualified
class references in text files, including XML, so from a practical
standpoint this isn't an issue.

> I think that later versions of Spring allow you to use @Annotations,
> so Spring will adapt and improve, rather than staying in one place and
> stagnating.

Annotations are neat-o, but inappropriate for many problems, of which
DI is one. The goal of DI is to separate the concern of wiring
application components; peppering DI annotations throughout a codebase
isn't separating anything. Moreover, they entail a close coupling to
the DI framework (be it Spring, Guice, EJB3, or whatever) that is
undue. Consider a generic library/framework consisting of a graph of
POJOs used by several projects that each use a different DI
framework. Should the POJOs contain a sum of the annotations from all
the DI frameworks?

> As for inversion of control, I don't think that it is such an amazing
> thing as to justify an entire framework.

Indeed, those that employ DI might prefer to write the wiring code
manually, and I certainly wouldn't argue with that approach. Perhaps
the appeal of Spring is that it standardizes the pattern. Of course,
Spring entails other value-add features such as AOP and factory bean
awareness, and some might find the XML-config approach convenient.

> I think GWT is better than Spring MVC, passing a java object back to
> the client side is just too cool. But all the freebies I get with
> Spring MVC are way better than any of the other 'server side'
> frameworks I've seen.

I love GWT and use it on web projects whenever I can; never used
Spring MVC.

> One of the things I see a lot of is Hibernate still being a required
> skill on projects. It doesn't seem to have sunken in that:
> EJB3 > Hibernate

Some might use Hibernate simply as an EJB3 implementation. I have
(but must confess to find occasion to use some Hibernate-specific
annotations...)

> Also, Java EE 5 is a nice conceptual fit with JAX-WS, since they are
> both @Annotation based frameworks. I think JAX-WS is one of the more
> amazing hidden secrets of Web Services. I guess because the SOA
> pushers would find their business collapsing if Web Services became
> easy, and JAX-WS makes them incredibly easy indeed.

Some might argue that contract-first is the proper methodology for web
services, but I myself find JAX-WS too convenient to ignore.

[Rick]

> The goal of DI is to separate the concern of wiring application components;

That is an interesting definition. I'd have said:

The goal of dependency injection (DI) is to solve the design problem
"how do these two objects know about each other?"

[Kevin Wong]

I have to disagree. There are simpler solutions if the goal is simply
to solve the dependency problem, e.g., singletons, factories. The
goal of DI is not only to solve the problem, but to do so in such a
way that values and adheres to the principle of separation of
concerns.