Hacker News new | ask | show | jobs
by threeseed 4065 days ago
There is no doubt this combination would be extremely high performant e.g. Wildfly was always in the top handful on Techempower benchmarks. But using JSF and EJB is a pretty extraordinary combination to be using these days. You would honestly be laughed out of every Java development team for even considering it.

Would definitely like to see why something like Dropwizard, Vert.x or even Play 1 wasn't considered.

3 comments

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)

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.

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

Not extraordinary if you're an enterprise shop. What's not cool and old school for startups is probably the widest used web / services framework in the enterprise world, vying only with Spring and ASP.net

There are probably more java EE jobs out there than ruby ones. (It doesn't say anything really, except the fact that some places don't laugh at you if you suggest Java EE, some places would laugh at you if you suggest anything else)

Sure it's not extraordinary to still see them used. But suggested for a new project ?

I've spent at least 15 years in enterprise companies and most new projects I've seen have been Scala/Clojure/Java 8 style in microservices form. Less so the monolithic WAR style apps.

Not dismissing the choice at all. Would just like to hear more about why they are bucking the popular trend.

>But suggested for a new project ?

I'm seeing this a lot. If you browse the site the article's on you'll find some more examples.

The moral of the story is that "we" all think Java EE is very enterprisey and that it's anti the popular trend (which is AngularJS, Node.js, or were those popular yesterday?), and meanwhile a couple of startups are being very productive and able to start quickly with modern Java EE because "nobody" has realy noticed that Java EE slimmed down so much and got so much more productive.

I guess it depends on the "hard core" ness of the enterprise. Walmart and such? Yes, scala / dropwizard / Vert.X and even Node.JS can be popular. Bank of X? X insurance? You will be suggesting even to upgrade to the latest Java EE and look like a crazy revolutionist.
>But using JSF and EJB is a pretty extraordinary combination to be using these days. You would honestly be laughed out of every Java development team for even considering it.

You'd be surprised.

I don't even know where you got that idea. BOTH are widely deployed and used in enterprise.