Win a copy of Transfer Learning for Natural Language Processing (MEAP) this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

EJB 101 Damnations

 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What would you all say has changed about any of these EJB Damnations ?
Some of these are "old".
EJB 101 Damnations
Matt Stephens the editor of (and regular contributor to) a satirical website for software developers and managers. You are looking at it.
regards
[ September 09, 2003: Message edited by: HS Thomas ]
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didn't think a lot of these were valid back in February 2002 when it was written. The author doesn't seem to understand the technology (EJB) or their purpose (Enterprise Applications).
For example, the very first point is way off base:

EJB Damnation Point 1
EJB represents a radical departure from the Beans model. Beans was based on the (proven) component model also used in Delphi. This means that for projects that are migrating to EJBs, much of their code base is no longer valid.


No really? The EJB component model was designed to solve a completely different problem. This is comparing apples to oranges. Anytime you move a client/server application to an n-tier enviroment you are likely to throw away quite a bit of code. This point is pure rubbish and has nothing to do with EJB.

EJB Damnation Point 3
EJB is based on an Object Pooling optimisation. Optimisations should not be incorporated into the design, but left for vendors to decide and compete on. The logic of basing a system on saving a resource as cheap as memory seems absurd.


According to who? Object pooling is not mandated by the EJB Specification, it is just recommended and supported in certain cases. Furthermore how would like change the landscape of EJB? Every vendor is and would still be doing object pooling.

EJB Damnation Point 89
EJB exposes Java to attack, not from criticism, but from a better language. Not talking about C#, but a language based on Components and Stores instead of classes.


I didn't realize that EJB was a language. I thought it was a component model implemented in Java. :roll:
The list continues to make these types of absurd statements. Overall, it is a ridiculus article that makes terrible assumptions and wrong conclusions.
 
Chris Mathews
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, this article was discussed on TSS back in February 2002. Here is a link to the thread.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've never seen the Holy Grail of using EJB, even when working on projects where they should (according to the hype) be used heavily.
All those projects worked out well (technically that is, 2 were failures for non-technical reasons).
IMO the ONLY reason to use EJB is to expose data to applications running remote from that data AND needing complex interaction with those applications in order to store and retrieve that data correctly.
And for that too other mechanisms can be employed that are easier to implement, more transparent and better performing (like web services, SOAP interfaces, etc. etc.).
As Rod Johnson states in his book "J2EE design and development" "EJBs add unnecessary complexity to such {non-distributed} systems. An EJB solution can be likened to a truck and a web application to a car. When we need to perform certain tasks, like moving large objects, a truck will be far more effective than a car, but when a truck and a car can do the same job, the car will be faster, cheaper to run, more maneuverable and more fun to drive".
I think that pretty well sums it up.
[ September 09, 2003: Message edited by: Jeroen Wenting ]
 
What could go wrong in a swell place like "The Evil Eye"? Or with this tiny ad?
Two software engineers solve most of the world's problems in one K&R sized book
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic