Hacker News new | ask | show | jobs
by john-waterwood 4065 days ago
JSF and EJB are the reason why Java EE is lately considered the "secret weapon".

The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies.

EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called stubs and skeletons, just to do hello world.

Modern EJB on the other hand is a POJO with a single annotation:

    @Stateless
    public class Bean {
        // do something 
    }
That's all. There are no required framework or business interfaces, no obligation to put ejb beans in a separate EJB module and there are no specific compiler tools needed. It's a total day and night difference.

In modern Java EE there's no reason whatsoever to avoid EJB.

There's a similar story with JSF. The first versions (1.x) were mostly POST focused, had heavy session space requirements, and components were hard to create.

In modern JSF 2.x, there's first class support for using GET, and the PRG pattern is at the heart of interactions that are logically POST. Session requiremebts are largely minimized by use of a partial state saving (only changes to state are saved) and a stateless mode (nothing is saved). You can use plain html to author pages with a single extra namespaced attribute to mark it as a component to JSF.

Again a night and day difference and no need to avoid it anymore.

Then JSF has a number of very cool extensions available such as PrimeFaces (beautiful visual components) and OmniFaces (Swiss army knife like Guave is for plain Java)

3 comments

The fact that people that have used Java do not realize that EJB3 is pretty good, when it's pretty old! I switched to EJB3 in 2006, and I really couldn't see why people would choose Spring anything instead. The switch to Soap, and then to Rest, was changing a couple of annotations. Not bad for a 9 year old framework.

Now, my biggest problem with the stack, and the reason I do not use it anymore, is Java itself. A switch to Scala makes a lot of the Java boilerplate go away, and even Java 8 doesn't get close. Now, I find all the major Scala web libraries to be lacking, in one form or another. Play's second compilation feels clumsy. Spray's freedom of routing leads to very ugly code: Just look at their own large examples. So what I am currently doing is using a homebrew routing on top of Spray, which also gives me some documentation for free: Pretty useful when you have hundreds of services in hundreds of servers.

It's a pity that Java itself moves so slowly, and is so reluctant from adding key features, like pattern matching, because the rest of the tooling is pretty good.

Yeah, EJB 3 is itself really not that new, but it took some time for implementations to come out. JBoss AS 5 took ages and EAP even longer. Then people had to upgrade from their older versions and then had to discover how much the new APIs had improved.

I don't have hard numbers, but judging from popular comments online I'm carefully guessing that it wasn't until ~2011 until people really started to see how simple EJB had become.

The old stigma still clings to it, much undeserved.

> I really couldn't see why people would choose Spring anything instead

Testing. Updates and fixes not tied to server releases (which can take years).

Fixes don't take years with Java EE!!!

We're using JBoss and there's an updated version mostly every few weeks, months at most. Absolutely not years, that's totally ridiculous and tells me you've never really used Java EE.

JBoss still doesn't have a supported Java EE 7 server. JBoss releases still much less frequently than Spring. If you want to look at how quickly things are fixed in JBoss have a look at this: https://issues.jboss.org/browse/SECURITY-746

If you need a feature in Java EE you have to wait several years for the next Java EE release and several years more for the next server release that implements this, see JBoss.

You're mixing up things.

JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/

You're quoting an individual bug that has been open for some time. Did you also looked at the many bugs that were fixed after a few hours after being reported? Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?

Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want). That's the time between 2 spec releases. It's about the same time as between major supported JBoss releases, so between EAP 5, 6 and 7. There's 3 to 4 years between major Spring releases (Spring 2 2006, Spring 3 2009, Spring 4 2013).

And Java SE doesn't release a major new version montly, let alone yearly either. A spec should move fast enough to stay relevant, but slow enough to provide the stability needed so lots of other technology can build on it.

> JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/

http://jbossas.jboss.org/downloads

EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months

> Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?

In about 50% of the times I have reported bugs or submitted pull requests against Spring they were closed within 6 hours. Spring releases about a month apart. The other 50% lay dormant for years. Still way better than any contribution I tried to make so far to Java EE. 0% success in about 6 tries.

> Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want).

https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edit...

Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years

> In modern Java EE there's no reason whatsoever to avoid EJB.

I don't see much reason to use it, either. The only exception is for distributed transactions, where session beans serve as nice abstractions as entry points and managers for the transactions.

>I don't see much reason to use it, either.

For regular transactions (local, one transactional resource involved) they're still pretty handy as well. EJBs also have things like @Asynchronous, @RolesAllowed and the timer service. The @Stateless concept itself can be just the right abstraction as well.

Eventually though the EJB model will be decomposed and its services made available via CDI.

This is NOT because the EJB model is bad or unworkable, but because it makes sense to align everything on a single component model.

I don't understand how "sucking less" makes JSF a secret weapon. What advantages does it provide over other, simpler ways of managing templates and views?
Let's turn it around, what do these "other" ways have as advantage?

It's not sucking less, it's completely not sucking at all. JSF is very powerful and easy these days. I've dabbled in various other technologies, and I think they pretty much all sucked and where much more complicated.

I do like AngularJS 1 somewhat, but it's a client side technology which has its own set of disadvantages (remember why Twitter went back to serverside generation of "ready-to-render-html")