3 ms·
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 w
by jbverschoor 1y ago
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
- brightball 1y agoI 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).
- datavirtue 1y agoYeah, 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.
- liveoneggs 1y agoresin was okay but I never got what it offered over tomcat
- jbverschoor 1y agoFull 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
- icedchai 1y agoEntity 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.
- xienze 1y agoYou 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.
- icedchai 1y agoI 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.
- zmmmmm 1y agoThe 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.
- icedchai 1y agoYes! Hibernate was awful, but still light years ahead of EJBs. I worked on a couple of Hibernate projects and always left asking why...
- jbverschoor 1y agoI 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