[CookWithMe]

Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it.

Two examples from my experience:

JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0].

Hibernate is probably the worst offender. Well, the interface is somewhat nice: you don't have to care about loading objects from the database, Hibernate will load them for you. One object, one request at a time. Looking at the hundreds of generated SQL requests it's quite easy to figure out how you would write better SQL... but you don't write the SQL, Hibernate does :)

The lesson IMO is: If you're writing everything from scratch, language performance is important. If you're using frameworks, the performance of the whole stack is way more important and one should probably compare benchmarks - or even real-world applications that are similar to ones use case - of the whole stack.

[0] http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html

[vetler]

Well, to be fair, Hibernate is just a tool - and as many tools, it can be used the wrong way and the right way. Most people seem to not spend any time to learn how to use it, and then complain when it doesn't magically read their mind. It's leaky, like all abstractions. You have to understand how it works, and how databases works. There's always the option to write HQL or JPQL as well, or even fall back to SQL if all else fails.

It's not Hibernate's fault that you eager load everything, always load entire entities when you just need a single boolean field, or loop over entity collections to aggregate values - Hibernate is just a tool, and it's the developers who are telling it what to do.

[saiya-jin]

true, but... if so many developers end up having issues on not-trivial-hello-world-employee-customer example, then maybe, but just maybe it's not the best tool for most. I mean, it's around for ages, the principle didn't change a bit, and same issues again and again.

One thing that I don't like about Hibernate - most projects evolve, for a very long time even after delivery. Messing with OR mappings (which most changes do) can include a lot of regression on performance side, much more than SQL (unless you do something horrible on DB level). Also, the more complex data model is (and often you don't choose how it's done), the less benefits you get from solutions like these.

[xtrumanx]

What's wrong with having six lifecycle stages? I don't use JSF (or Java) but I can understand the usefulness of having several lifecycle methods assuming you can hook into them and add your own custom logic. The more lifecycle stages the more precisely you can choose when during the request processing your custom logic should be invoked.

[CookWithMe]

You're right, there isn't anything wrong with the six stages per se.

The root cause is really that (a) they're forcing a stateful model onto the web and (b) that the way they're keeping/restoring the state is expensive.

The lifecycle stages are more a sympton of that. Most web framework these days go with a stateless approach. One notable exception is the lift framework for scala (although I'm not sure if it's really active anymore). I have only looked very briefly at it, but it seemed to give the programmer more explicit control of the state...

A simplified example to demonstrate the problem: Imagine a B2B app with a medium-sized table, where each row contains multiple objects. A HTTP request is send for performing an action on one object.

In a stateless approach, the programmer decides which objects he needs to serve the request. In JSF, the framework restores the complete state as seen in the previous request, and will also setup a lot of other magic (event handlers, validators, what not) - no matter whether it is actually needed to serve the request or not.

So one ends up with stages in the lifecycle that waste a lot of time, but one really hasn't much control over.

[xtrumanx]

Oh sure, the stateful model thing you mention definitely sucks which is why I hate using asp.net web forms and prefer asp.net mvc at the office.

Both of them have lifecycle methods, (for app start, request start, request end, etc.) and for the most part I completely ignore them until the day I need to use them and I'm glad they exist because the alternative would have been writing a code in every endpoint of my application.

[fddlr]

You don't have to use all Hibernate features. You can write your own SQLs too if you want to. Hibernate can be super fast if you use the correct strategies [1] at your bottlenecks. Any other performance issues are typically ORM related.

[1]: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/p...