[hildaman]

I don't understand your comment.

To me the beauty of JEE on the backend is: 1. Scalability - the application server creates as many instances as needed - until it hits either the JVM limit or the machine limit. 2. Declarative transaction management so I can write reusable code that interacts with the database without having to worry about transaction boundaries. 3. Excellent and portable Object Relationship Mapping (Java Persistence Architecture).

On the front end, with JSF webpages can be developed very quickly.

There are a lot of other things you get with JEE like Asynchronous Messaging (JMS) - built in.

There is a reason mature organizations worth billions of dollars and with highly skilled architecture teams have settled on JEE as the defacto standard for their information systems.

There is definitely a learning curve with JEE, and someone fresh out of school will need a year or two to really understand how it fits together - but when you write something in this framework, it is easy to read, maintain and rarely needs to be re-written.

Most importantly, the framework will continue to be developed for the foreseeable future - I mean multiple decades.

On the other hand, some of the newer javascript stuff - is horrible broken spaghetti code that is glued together by spit and prayer. 99% of these frameworks will fall out of fashion with the associated problems that come with falling out of fashion - the canonical example being Ruby On Rails.

[devonkim]

You're looking at this ecosystem after we've already gone through multiple versions of EJBs that are all very different from each other, several different JMS implementations from many vendors now deprecating them (IBM is deprecating a couple of their JMS implementations for cloud services in favor of a hosted Kafka offering, for example), and the endless XML-based configuration of all services and their components combined with a lot of tight coupling requiring different services to be re-deployed upon updating their EJB entities or face class unmarshalling problems. I'm not a fan of sloppy configuration, but there is historically far too many things that were necessary to configure to get a basic JEE service started.

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...

[hildaman]

Your last paragraph just made my point for me.

Once you get out of toy frameworks that won't scale, refactor or "age well" - you end up with a JEE style framework.

It's like that famous cliche about unix - "Those who do not understand Unix are condemned to reinvent it, poorly."

You are right about older versions of JEE being a pain in the ass to use - but that critique hasn't been valid since 2004 when EJB 3.0 was released - 13 years ago. JSF is really slick for front end development.

But even prior to the release of EJB 3, can you name any EJB equivalent (from the pain in the ass xml era) that is still used, supported and actively developed?

We literally still have 15 year old EJB's - that "just work". People just inject them into the new EJB's they write and they work!

You might think rewriting services to keep up with the latest and greatest fad is a productive use of your developers time - but I prefer to have my developers focus on solving new - revenue generating problems, with building blocks that have already been written instead of constantly reinventing the wheel.

We have a mix of American developers (junior, mid-level and senior), offshore developers in 6 countries, and H1-B developers - all of whom are paid at or above market rate for their work (150K+ for the State side workers). I don't think any one of them considers themselves "disadvantaged" in any way because of the technology stack.

They understand that they have problems to solve and JEE are a tool to solve their problems and I am sure they grateful we aren't making them re-write 15 year old code to keep up with the latest fad.