4 ms·

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 a

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.

hildaman 9y ago
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 9y ago
  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_approach https://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approa...
cratermoon 9y ago
Much of Java EE was driven by IBM: EJBs are in a broad sense a Java wrapper around CICS transactions.
- philippeback 9y ago
  Done wrongly.
  - cratermoon 9y ago
    Very Wrongly
watwut 9y ago
" 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.
- devonkim 9y ago
  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.
- watwut 9y ago
  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.

hildaman 9y ago

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 9y ago
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_approach https://en.wikipedia.org/wiki/Worse_is_better#The_MIT_approa...

cratermoon 9y ago

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

philippeback 9y ago
Done wrongly.
- cratermoon 9y ago
  Very Wrongly

watwut 9y ago

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

devonkim 9y ago
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.
watwut 9y ago
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.