Hacker News Reader

Comment by lukaseder | Hacker News Reader

At a previous employer, we've migrated a complex J2EE (with EJB 2.0 and such) E-Banking system to use only Jetty and JDBC directly. No one in operations noticed the difference.

But the developers did. Oh they were about 5x as productive afterwards. With no missing features.

Perhaps I'm not included in the target audience. But if E-Banking can do it, what remains of the "target audience" ?

View on HN

Agreed. It's also possible to use frameworks such as Spring Data/Boot, Roo or Grails to get started really quickly - a bit like the django/rails crowd. Lots of interesting things happening in Java world at the moment.

It seems like originally Java drew from the mega complex enterprise application world influenced by people building large scale C++ apps etc so were hardly aware of the complexity they were adding. Now there is a lot of influence from modern web frameworks to quickly developing and expanding an app.

Touch to maintain some of those old Java apps though from 5-10 years ago in some cases.

The problem with Grails is, like you said, it focuses on getting started quickly, rather then producing a maintainable and performant codebase. I mean, Hibernate is very complex in itself, and adding another layer (GORM) on top of it won't make things better. If I were to start a new java project, I would probably choose Dropwizard (http://dropwizard.io/), which is more a collection of libraries then a framework.

The business model of the Grails development has always been about integrating various existing software into one branded product for "full-stack" development, such as Groovy and Spring. The Spring and Grails crowds inside Vmware seem to do everything together now (e.g. SpringOne2GX conferences) so I suspect they're now already one group, and that it's the Grails project that's taken over Spring just like they previously took over Groovy.

"But, but.. it's not enterprise!!!111"

How are they going to justify their consultant fees then?

Thank you very much for this comment.

We have a pretty complex Java EE 7 application but we migrated from JPA to pure JDBC (obviously with abstractions so we can support multiple database implementations, but our current only implementation is PostgreSQL). So it's mainly CDI, JAX-RS (RESTful API), JDBC and timers, and it's pretty great performance-wise and developers are kept fairly productive.

You might be interested in jOOQ: http://www.jooq.org

As much as I agree that J2EE is bloated, the fact that you can migrate a project to a less bloated stack and still run it proves nothing. The whole point of the whole "bloatiness" is so that supporting/changing the system in the the long run will be faster, easier, and cheaper.

The question is if the 5x productivity boost in-between the changes in the system yields more value or not. Which I believe it does.

May be true for J2EE. Java EE plays in a different league.

Reply on news.ycombinator.com