Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012 | Hacker News Reader

Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012

javacodegeeks.com

44 pointsmarkokocic39 comments

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.

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

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.

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

There's a huge difference between a programmer that uses Java and a Java programmer.

One is someone who uses tools to accomplish their goals, the other is someone defined by their tools.

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

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.

I remember jsf having a bad rep however jsf2 is supposed to be not as bad.

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.

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.

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

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

Have you tried Play (playframework.org) yet?

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

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.

Yes I've tried it (pre Play 2), and there's one thing I don't like - favoring/integrating certain tools in it. I know that it uses Hibernate through the JPA API, and if you want to use a different ORM you'll have to make a lot of workarounds. And it's not only about ORM. A month or so ago I read that it will integrate a certain JavaScript library in it too. Tapestry Web Framework had this attitude, but the developers found that it brought more negative than positive effect, I hope Play will see the same. Modularity and ease of configuration is a very important thing.

I like it's Scala support and enthusiasm though, and I will definitely try it some day again.

+1 Can't see any sane reason why either would be used for a new project in 2012.

Absolutely agree. I work with a very large "enterprise" (investment bank) and they deploy every one to two weeks. We wouldn't touch Spring or JEE with a barge pole. I don't know what world the author lives in.

are you using java at all, or something else entirely?

Scala or Java SE the way to go IMHO.

Scala is a language, not a framework. You can use Spring with Scala too [1]. Personally, I wouldn't use it for an enterprise project just yet, because of its compatibility issues. And why on earth Java SE? The enterprise edition gives you everything a standard edition does, plus libraries for messaging, transactions, persistence, basically everything you need to write a large scale enterprise app.

[1] http://www.infoq.com/articles/scala_and_spring

While Scala is not a framework, it can be used with many Java libs. It isn't necessary to use xml-heavy frameworks and app servers to write "enterprise" apps. Endless layers of OR-mapping and xml is not productive. There are endless messaging and persistence solutions available without resorting to xml-obsessed JEE and Spring.

@mgkimsal - yes java, moving towards scala on newer projects. We use simple, fast & testable solutions, such as a main class or servlet listener which constructs an application programmatically, rather than a monolithic spring or JEE configuration.

Could you tell us which framework you're using then? I know that most Java enterprise software is either on Spring or on EJB, I'd love to know if there's an alternative.

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?

Exactly my thoughts, I can't think of any scenario where JEE is a better choice than Play.

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.

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.

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.

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.

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.

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

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

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.

I second this. Please, put your money where your mouth is!

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.

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

And this is why I use noir.

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

This article is devoid of any dev value

Reply on news.ycombinator.com