Hacker News Reader

Comment by jbverschoor | Hacker News Reader

Oh yeah. I still don’t understand why we even moved away from the original JEE model, including the different roles (app dev, deployed, etc).

The whole spec was great with the exception of entitybeans.

It provided things that are still not available it anything else.. why do we store configuration/credentials in git (encrypted, but still).

And the context were easy to configure/enter.

Caucho’s resin, highly underrated app server. Maybe not underrated, but at least not very well known

View on HN

Entity Beans were terrible, representing the height of JEE over complexity. I remember editing at least 3 classes, a couple interfaces, and some horrific XML deployment descriptors to represent an "entity." A lot of the tooling was proprietary to the specific app server. On top of that, it was slow.

In the early 2000's, I used to work on JEE stuff for my day job, then go home and build PHP-based web apps. PHP was at least 10x more productive.

You have to keep in mind that entity beans were developed in a time before generics, annotations, and widespread use of byte code enhancement that made a lot of the easy, magical stuff we take for granted possible.

I remember. During the same time period, I wrote some Java apps that used plain old JDBC, plus some of my own helper functions for data mapping. They were lighter weight and higher performance compared to the "enterprise" Java solutions. Unfortunately they weren't buzzword compliant though.

The worst thing about EntityBeans is they were so bad they made Hibernate look good, which led people to think it was good. After 10 years of hammering against ORM complexity I finally switched to using thin database wrapper layers and have not once ever regretted it.

Yes! Hibernate was awful, but still light years ahead of EJBs. I worked on a couple of Hibernate projects and always left asking why...

I never had any trouble with Hibernate tbh. It allowed you to drop back to raw sql if needed, and also custom fields to select if needed.

I never understood the fight against ORMs. In the end you'll simply be writing your own framework

Only if you insist on a nearly 1:1 mapping between your data and your class hierarchy.

Hibernate... a real PITA every time the application needed something beyond basic single-table CRUD queries; sadly for me it happened 99% of the times. After some months of torture, plain JDBC with their stupid checked exceptions was refreshing, even without wrappers.

I you just wanted queries, entity beans were ok.

Just a lot of boilerplate code, but the overal architecture and structure of JEE is still very sound

A lot of boilerplate and XML hell!

What did you like about JEE? I worked in that world for years and don't miss it in the least.

You know what's funny? Spring (earlier versions) had even more xml ;-)

I dunno it just worked for me. But I kept using the standards, no vendor lockin stuff, which bea etc always wanted.

I think the servlet design is great, the whole packaging/deployment model is great. And then well the session beans were overkill in general, so they were swapped out quite early by me. Swapped jsp out for I think velocity templates. And that application is still alive, running, and on the same platform.

And Java meant, at least for me and how I configured it, proper debugging and IDE support (love Eclipse), hot code reload, easy releases, repeatability, ci/cd. The last 20 years, no __significant__ improvements in my opinion.

I think servlets are great, too. Coincidentally I also swapped out JSP for Freemarker and then Velocity templates pretty early. The session beans and entity beans I could both live without. The "heavy weight" nature of the commercial app servers really bothered me. JBoss was fine, but WebLogic, WebSphere, etc were awful.

I remember Resin.

I grew to be a big fan of JBoss and was really disappointed when the Torquebox project stopped keeping up (Rubyized version of JBoss).

Yeah, JBoss put "it's slow" to bed right away. I was doing my own research at the time and tried some workloads on it. Huge difference.

resin was okay but I never got what it offered over tomcat

Full JEE, not just servlets, performance, reloading, and a bunch of enterprise features. Resin existed.

After about 10+ years Spring kind of took over JEE.

Omg. Spring was just like moving code to xml. Different now, but still.

What I miss from JEE:

- single file ear/war deployment, today that’s a docker image

- the whole resource api from Java (filesystem/jar doesn’t matter). It means you don’t necessarily have to unpack the jar

- configuration / contexts for settings, + UI for it, database connections etc. Docker kind of works, most most images fail to achieve this. Docker compose kind of takes care of things.

- as said before.. all Java still runs everywhere

Reply on news.ycombinator.com