interesting - the members are a mix of people from around the world, including Oracle India (just as is Amazon India or Google India or Microsoft India).

Time to invoke SandGorgon's law of outsourcing analogies - "As an online discussion about PROGRAMMING grows longer, the probability of a comparison involving outsourcing or Indians approaches 1, if Godwin's law has not already been satisfied"

http://www.lambdacurry.com/2010/07/sandgorgons-law-of-outsou...

Isn't the whole J2EE business evolved for outsourcing IT work?

J2EE was designed for an era when big, monolithic entities were creating most of the production-grade software out there, SMP hardware was extremely expensive and capital-intensive, and open source software was largely considered a joke by those with the buying decisions. It made sense to try to target large entities that have developed decades of abstractions supposedly meant to reflect how complex (perhaps complected?) their business layer logic is and that their software architecture should be tightly coupled to it as such.

J2EE became a target for offshore software projects primarily because of its userbase being organizations that are fundamentally not software companies and that are constantly trying to cut costs while being unable to migrate off these systems quickly simply due to their sheer organizational inertia. These companies culturally haven't scaled based upon much more than bodies (a typical enterprise M&A is fundamentally more bodies and access to specific customer bodies rather than a strategic technology play given how slow M&A works in practice), and these are oftentimes the companies you see in newspapers that are experiencing business difficulties - what skilled, talented developers want to stake their careers working on software used only by a community that is in a multi-decade crisis?

Even if you spend a lot though, outcomes are not necessarily great either. US DoD is a great example of tons of J2EE on their backends with unremarkable outcomes despite having spent perhaps more dollars on software engineering effort than probably Google has in the past 30 years cumulatively (where the money goes is another topic).

It's tough problems as a large company that thought they were getting ahead of the technology curve back in the 90s and are now the dinosaurs and fossils.

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.

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

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.

" what skilled, talented developers want to stake their careers working on software used only by a community that is in a multi-decade crisis?"

What multi-decade crisis are you talking about? Not everyone is hipster afraid to learn abstractions or unable to comprehend them. There is learning curve to J2EE and especially early versions were hard to learn, but willingness or ability to learn is not exactly mark of no-talented developer. Low skilled untalented developers go for easy to learn technologies.

Integration projects are difficult for many reasons, technology choice is not one of them.

I guess someone does not liked to hear that. I still find the "I was unable/unwilling to learn technology x, it is too complex for me, therefore I am superior" logic completely illogical.

The crisis is primarily that many J2EE projects are fundamentally cost center projects designed to be written once and maintained by a low-cost team and are thus focused more upon compliance to standards and consistency than creative problem solving. If a business domain is well understood and documented, it is very straightforward regardless of software platform to codify its rules and conventions - this is not what happens in most software developed today. The culture in the J2EE community (that does have value, not devaluing the approach) along with its participating community of typically old, established companies with cultures not favorable to certain personalities (regardless of skill) has caused a huge brain drain from making usability (and therefore consistency IMO) improvements that could have been possible. It'd be really interesting to see what would have happened if half of Silicon Valley's engineers contributed to the J2EE ecosystem, but we will never know given the trajectory of the industry.

From my years doing integration projects for a lot of the F500 I've confirmed your assertion that technology hardly matters for them, but this makes it very difficult to grow as a developer because you're not solving technical problems anymore as much as business level ones. The "learning" involved at technical levels tends to become more about trivial (API inconsistencies from implementation, names of properties) or specific, proprietary knowledge gained from basically reverse engineering other parties' code. This also does not require any skill or much training either. Combined with mostly straightforward coding requirements, this drives down the skill level necessary to be successful in a usual J2EE software shop and thus the labor pool drives toward commoditization.

Much of Java EE was driven by IBM: EJBs are in a broad sense a Java wrapper around CICS transactions.

Done wrongly.

Very Wrongly

Sorry, I don't understand your point. Are you trying to say, JavaEE is bad, or outsourcing to India is bad, or the code quality is bad?

> Looking at the people who belong to this organization, I get the feeling that the majority of the JavaEE development was outsourced to India.

I don't see "bad" mentioned anywhere

I don't either, but I'm also wondering what the point was? There's ways that can be expanded that prey on stereotypes, and ways it can be expanded that don't, and the latter might have been an interesting discussion (e.g. India's growing population of software developers trained on Java, and whether that should garner them more influence of Java, and how that might affect it going forward as just on possible example).

Except for a few old white dudes.