I had a summer job working on EJBs at a company that had built everything on CORBA. It was basically a research project; they knew they had to switch to EJB, because it was going to be the standard (ha), and they wanted to know how. This was in the EJB 1.x era, so somewhere between 1998 and 2001 - i don't remember exactly when!

I remember thinking that it was all rather complicated, especially around persistence. And i remember being appalled that beans didn't actually implement their interfaces. We came up with some rather complicated pattern to work around that - i think there was a master interface where all the methods threw RemoteException, then the bean interface trivially extended that, and there was a local interface that extended it but overrode all the methods to not throw RemoteException, then the bean implemented that. And i spent most of my time there wrestling with the fact that the performance characteristics of local and remote calls are very different, and how that impacted design; we ended up with DTOs mirroring every entity bean to save network round-trips.

But the thing is, there was nothing else around at the time that did anything similar. Remote object invocation, with declarative transactions, and container-managed object lifecycles, including pulling objects out of a database on demand. That seemed like saucer tech! So it seemed, glaring design flaws aside, fair enough that it was complicated. Hey, i might have to write an XML document, but at least it wasn't ten thousand lines of C++.

People like to bash Java without understanding how things turned out as they did.

So, in some senses, at least the rabid drive toward implementing the full spec has been deprecated, if not the technology itself.

I was really green in enterprise software then, and Websphere's suggestion of useful clustering, configuration management, managed pooling, etc., seemed tantalizing. (Look how long it takes to start up--it must be doing useful and complicated stuff!) That said, it didn't take all that long for Tomcat, JBoss, and others to eat its lunch on projects not rolling along on enormous sunk costs into IBM tech.

I never actually dug into EJBs or wacky things like container-managed Javamail. Some colleagues did. They spent a lot of time struggling with the tooling.

And now I'm just remembering VisualAge for Java. /shudder/

Erlang is mainly about OTP. OTP delivered an opionated take on distributed components -- think of Erlang on OTP as Ruby on Rails -- and did it exceptionally well.

But one could still do this with Java btw. The specs are still there and they are solid.

In one job, i used an enterprise framework that actually predated Java EE. Several ideas in EE were copied from it. But incredibly, this framework was substantially better than early EE. I believe, because that framework was built by people who actually needed to ship products to customers to pay their bills, which limited the amount of overcomplication and obstruction they could get away with. There was no such limit on Sun's architects.

Am an early, vocal Java partisan. Java world HTTP servers fell into a ditch and kept digging. Servlets and JSP weren't too bad. Wasn't crazy about Tomcat or NetSuite, but ok. Then it just got more and more nutty. J2EE, Spring, XML, schemas, annotations, etc.

There's nothing about Java that rules out simple and quick. For medical records stuff, I replaced a huge J2EE/BizTalk style backend with stupid simple process runner for stupid simple tasks. Think Windows OS Task Manager running AWS Lambdas.

In conclusion, I remain sad about the enterprisey detour Java took.

For reference: https://martin.kleppmann.com/2008/05/11/ruby-on-rails-vs-jav...

> I believe that if there was a full standard distribution for Java EE (e.g. Icefaces+JSF+Seam+EJB3+JPA+Hibernate+Glassfish, to name just one possible API stack out of thousands of different combinations), people would write a lot more good documentation for that particular stack, and it would become a lot easier for more developers to start using it effectively. With the right tools and good documentation, productivity could potentially be about the same for Rails and Java, but at the moment Java is shooting itself in the foot in this regard.

Entity beans were always a disaster, and Stateful Session Beans had scaling problems, but Stateless Session beans by the time of EJB3 were an easy way to push logic out to the network while getting a whole bunch of stuff (pooling, scaling, failover, transaction management, security, etc) for free.

These days they'd be calling them micro services.

The main problem was combining everything into the big ball of mud that is J2EE. If they had let each component live and die on its own merits I think the ecosystem would be in a much better state today.

A lot of what's in JPA now came after Hibernate became such an industry-wide standard and because EJB 2's EntityBeans were so awkward. For early adopters in the 90s, EJB 1.0 was really, really difficult to work with and overall a frustrating experience compared to using Spring + Hibernate. This pain was much more keenly felt for enterprise software start-ups that couldn't afford release cycles and deployments that take so much time.

JMS is not the end-all be-all of enterprise messaging either and the J2EE ecosystem made certain technology innovations more difficult due to its byzantine nature. The AMQP working group came out of their frustrations with JMS and it includes a lot of experts with JMS implementations from the usual vendors.

I challenge you to find communities of developers other than H1Bs, older, offshored, and other disadvantaged (and in no way technically deficient either!) workers that are writing anything with EJBs for their jobs these days. Look at the career possibilities for these places as an engineer - do you imagine IT outsourcing and banking backends is something highly motivated and talented engineers would find fulfilling when there's other options? Furthermore, I challenge you to find operations teams that enjoy supporting these systems compared to architectures built around microservices / SOA using lightweight containers using, say, Kubernetes. J2EE architecture is simply not easy to maintain in production with typical enterprise sysadmins despite the billions spent on improving them over multiple decades now (and due to the hostile atmosphere of enterprise software vendor-client relationships impeding technical progress since time immemorial), and this is a deal-breaker for large organizations that are trying to reduce operations costs.

Even though ultimately we as an industry seem to be reinventing the wheel constantly probably to keep ourselves busy rather than to build highly maintainable software, this is preferable to millions of developers around the world in a monoculture writing constantly refactored and improved COBOL and Fortran if we approached the world of software with the JEE vision. It's been shown academically that for software reliability and maintainability, if you need to rewrite more than a certain percentage (I believe it was around only 30%) of the software, it is more economical and practical to rewrite it all. It is the rigidity of the JEE vision and competing enterprise standards that made interoperability and thus freedom for motivated, creative developers difficult that pushed them away from both larger companies and toward smaller companies united by open and probably less stable ecosystems. Moreover, it is really difficult to argue that the MIT Approach [1] fits everywhere in the software world and also that there is no merit to Worse is Better.

It's funny that you mention RoR in that there's been some concern by the community that it's becoming more like J2EE. It's a bit sad in a way because if everyone writing mature software winds up ultimately implementing J2EE, it has shown how little progress we've made as a software community despite so many different software design philosophies gaining market traction.

[1] https://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approa...

OTOH, the servlet API is nice.

I always remember when EJB's first appeared on the scene as a cure all - but EJB1 wasnt. Session beans were ok - but Entity beans werent that great

We didnt unit test as much as we do now. There were early versions of junit - but it was difficult to configure in an enterprise environment. So you would go to workplaces and people would tell you they were testing - but then you look at the code and there were few tests

It was a different time: the product was a combi of perl, php, c++. And then the business world, at least here, went over to java backends.