Bitter EJB

Michael Yuan writes "Enterprise JavaBean (EJB) is one of the most widely used technologies in enterprise Java. It is designed to be a scalable and flexible distributed framework. In EJB, almost everything can be done in several different ways and it offers the developer the maximum flexibility to choose the right approach for the project in hand." Yuan provides a review, below, of Bitter EJB, to guide programmers interested in large-scale Java development. Update: 10/27 18:27 GMT by T : Peter Wayner provides a somewhat deeper look at the book as well, also below. Bitter EJB author Bruce Tate, Mike Clark, Bob Lee, Patrick Linskey pages 412 publisher Manning rating 9 reviewer Michael Yuan, Peter Wayner ISBN 1930110952 summary Anti-patterns in Enterprise JavaBean development

However, every coin has two sides: the other side of "freedom of choice" is "complexity". Although EJB is an incredibly powerful tool in the hands of experience architects, it is subject to a lot of misuse by novice developers who do not make sound choices. For example, some developers might use a BMP entity bean to map each database table in the system; or access entity beans directly from a distributed layer; or store large amount of data in session objects ... The list goes on. Although those approaches are technically possible, they are hardly the most efficient ways in most cases. Such problems have not only caused many projects to fail but also tarnished EJB's reputation. In fact, the complexity of EJB is often quoted as an argument for other enterprise platforms.

For EJB developers, it is crucial to learn from other people's experiences and follow proven best practices. That helps to reduce the complexity of the platform. Manning's "Bitter EJB" is a very timely book written by well-known experts in the EJB field: Bruce Tate, Mike Clark, Bob Lee and Patrick Linskey. Unlike other "architectural" books, Bitter EJB teaches best practices through common mistakes (anti-patterns). It focuses on "what not to do" but still encourages developers to come up with liberal (everything not forbidden is OK) and innovative solutions. After all, EJB is about flexibility and freedom of choices.

Part I of the book is an overview of anti-patterns in the EJB specification. The EJB specification itself has several major design problems when it first came out in March 1998. EJB v1.1 and v2.0 have gone great length to fix the anti-patterns in the specification. But early adopters may have already developed some anti-patterns in their applications. For new developers, the history also serves as a valuable lesson on what EJB is really for and how different components in the specification fall into their current places. In this part, the authors also provide an excellent recount on what went wrong in the high profile TSS Java PetStore benchmark.

Part II is about session and message-driven beans. Those beans are mainly used in the integration layers. Topics covered in this part include how to deal with large database results, whether to maintain session states, the limitations of XML and much more.

Part III covers EJB persistence. Entity EJBs are probably the most confusing types of components. Many experts have advocated to abolish entity EJBs altogether in favor of other simpler persistence frameworks such as the JDO or even simple JDBC facades. The authors discuss the pros and cons of entity EJBs and covers most leading alternatives. For those who must use entity EJBs, this book also offers useful advices on a range of topics including how to reduce round trips, shorten primary keys and handle expensive database joins etc.

Part IV covers broader topics including performance tuning, testing, building and packaging. One big problem that even EJB developer can recognize the complex deployment descriptors. One chapter of the book is dedicated to reduce code duplication, automate the deployment process and avoid the "integration hell". The last chapter of the book provides an overview of "what's next" in the EJB space.

Overall, it is an excellent book for all EJB developers and other enterprise developers who want to learn from the successes and failures of EJBs."

Peter Wayner's review:

Although there may be as many 36 plots in all of literature, the compartively new world of computer books has really had only one: this new technology is simple, very simple, and it will make your life better and your teeth whiter. Bruce Tate opened up a second plot in his book Bitter Java by exploring just how even the best programming ideas have dark sides. Now he's back with three other authors exploring the world of Bitter EJB.

This book is more fruit from the same tree. Or, to hack the Java MemeStream even more, more beans for the same mill. If you use Enterprise Java Beans (EJB), or think about using them, you should read this book to see what can go wrong. The title shows how naming schemes can be misleading because either the authors aren't really that bitter, or because they're focused entirely on EJBs. This book does not belong in the same camp with the Java==SUV crowd. These authors are really admirers who just want to warn people how to avoid problems with Java and EJB.

Tate and his new co-authors, Mike Clark, Bob Lee, and Patrick Linskey are all consultants who seem to use Java a lot, at least when they're not cheating death. One of the cuter grace notes in the book is a collection of war stories from extreme sports that are mixed in as an allegorical taste of what's to come. Before exploring the problems with a Java concept known as enterprise beans, they tell a kayaking story that ends with the sentence, "Then we hear a loud crunch and look up to see Eric's stern stationary at the top of the drop, revealing the sitaution that every kayaker dreads the most -- the vertical pin."

After stories like this, the book goes on to explore just how the very fancy enterprise beans toolkit can produce an application that moves slower than a stream filled with honey. Each chapter is filled with antipatterns, or lessons about the software learned the hard way. They're sort of like points on the map that say, "There be dragons here."

The book is divided into four parts. The first section, termed "The Basics," explores the simple ways that EJB technology goes bad. The toolkit was heavily hyped as the perfect solution for building business websites that interface seamlessly with large databases. As the business grew, new servers could be added without grief. Alas, as this section points out, there are many reasons why an elephant gun can be the wrong weapon for getting rid of mice in your house.

The next section on "Networks and Messages" describes how good ideas can turn into slow code when people misuse the fancy tools for scaling EJBs. In theory, the EJB toolkit will split up processes simply across multiple machines to handle more customers, but in practice all of the communication can slow things down considerably.
The section on "EJB Persistence" describes how the much-hyped system for seamlessly storing away enterprise beans in databases can weigh down a system. My only beef is that they left out much information on Prevayler, a much-maligned and misunderstood ultra-light toolkit that is like an anti-EJB persistence layer in every possible way. I'm enamored with it, if only because it's such a radical move away from the monolithic APIs like EJBs. While they liken using EJBs to snowboarding in fresh powder with a 100lb pack on your back, Prevayler is sort of like boots-only hiking.


The last section isn't about EJBs per se, but similar toolkits and projects that often get used with EJB. There are antipatterns to avoid with JUnitPref and Ant, too. Some of these suggestions, like some in the rest of the book, aren't terribly new or brillant, but it can't hurt to get another lecture on the importance of testing your code.

The book shines when it's exploring what goes on behind the slick facade of the API. Sure, the EJB toolkit will dutifully load up data from any object on any server in your farm, but you better be careful invoking some of these these methods because the network is slow. The book often points out how invoking that one simple method from the sales literature can start up dozens of sluggish threads. Peeling away the layers helps understand and explain why the system fails.

Many of these lessons aren't limited to Java or EJB. I wouldn't be surprised if the group of authors was busy rewriting the book with examples from .NET. Unfortunately, some programming problems are very hard, and building a toolkit with a simple API won't make them go away. In fact, the simple appearance can cause more trouble when the programmer can't understand what the secret mechanism inside is doing. Almost all of the problems in this book arise from programmers who believe the sales literature when it tells them not to pay attention to what that little bot behind the curtain is doing. If you're working in the world of EJB consulting on big iron, then you've got no choice but to start thinking about what's behind that curtain.

You can purchase the Bitter EJB from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. Peter Wayner is the author of 13 books including Java RAMBO Manifesto and Translucent Databases.

Comments

Where's the review?

[Anonymous Coward]

This article reads more like a summary.

Brief?

[Johnny5ive]

For a review, this seems a bit short.

A quick overview of what is contained in the book is informative, but not necessarily insightful.

Gotta point that out; sorry for nitpicking, but I like book reviews to tell me not only what's in the book, but how good the book is.

Astroturfing EJB

[SunPin]

Be sure to check /.'s disclaimer before reading this marketing trash...

Principals of Slashdot and OSDN may have investments in the stocks of the companies discussed on this site and will disclose any interest if they are posting a story about those companies or their products. Contributors to this site may or may not have an interest in a company or product they are discussing. The decision to disclose that information is theirs to make. We do not guarantee the veracity, reliability or completeness of any information provided on our site or in any hyperlink appearing on our site.

Write better summaries and your subversive marketing might actually qualify as subversive.

Worth Learning?

[humandoing]

How many people have had really good experiences with EJB's? In over 3 years of doing Java development I have yet to hear anyone say anything good about developing with them.

The vast majority of people who I have talked to seem to indicate that they have never come across any project under development where using EJB wouldn't be complete overkill, and that much simpler, easier to maintain, and cheaper solutions seem to be the path chosen.

These aren't all small projects either, I would venture to say all of the people I have spoken with (or projects I have been working on) have been in the $50,000 - $2,000,000 range, and none of the senior developers or architects on these projects have ever dreamed of going anywhere near EJB.

Thoughts?

Re:Worth Learning?

[Anonymous Coward]

EJBs (particularly Stateless Session Beans and Message Driven Beans) are a fine solution for distributed multi-tier architectures. They scale well, can be transparently clustered and provide integrated end to end security. Even Entity Beans (when used correctly) can be quite valuable for write-intensive applications.

The biggest problem with EJBs is poor developer understanding of how to use them. Not just technical nuts and bolts, but problems such as innapropriate long-term use of Stateful Session Beans and exposure of Entity Beans in a non-local configuration. The pain of actually implementing EJBs has been largely eliminated thanks to tools such as XDoclet and EJBGen.

One of the nicest things about modern application servers is transparent web service publishing from Stateless Session Beans. You can get all of the advantages of a Java application server for your business logic (connection pools, load balancing, clustering, security, etc.) while providing access to non-Java clients.

Re:Worth Learning?

[Anonymous Coward]

Our worst choice was to use a Swing front-end instead of Struts.

What the hell are you talking about?

Struts is designed for web, html based front ends with serverside processing. Swing is for desktop apps that you don't intend to run in a browser.

If you want it to run in a browser use Struts, if not use Swing or SWT.

Re:Worth Learning?

[pHDNgell]

EJBs, and Java in general, are almost always entirely the WRONG approach to producing websites.

EJBs usually, java, no. The servlet architecture is one of the best things to happen to web development as far as making highly scalable web applications.

To make an efficient site, use a scripting language like Perl [or OCaml, but I declare an interest in that], write CGIs, use mod_perl to make it run efficiently, and where you want to optimise, put your logic into stored procedures. Templating and SSIs are also useful.

This is amazingly wrong.

First, OCaml's a compiled language, not a scripting language.

Scripting languages do not make a site more efficient. They might make the developer prototype more efficiently, but they aren't going to run more efficiently than something that's compiled, and in many cases, they'll provide you with surprising results later on.

Even then, I often write my struts actions in python for development. I've got a struts action that allows me to write them in python or bsh, which saves a ton of development time at the cost of runtime efficiency. Being able to write a two-line struts action is nice, though. These should be ported to java before I expect to them to handle load, though.

A well-written CGI will be less efficient than a well-written servlet, especially under load.

mod_perl is great if you can stand to write perl, and can do it carefully, but there are plenty of problems with doing this.

Putting your logic in a stored procedure will give you the opposite of scalability. The database is generally the most expensive resource in an application, and is the most difficult to distribute. You want your logic as far away from this as you can possibly get it.

Re:Worth Learning?

[Anonymous Coward]

Our worst choice was to use a Swing front-end instead of Struts.
I doubt it. Struts is as bloated as the EJB spec. There is very little reuse in Struts. You made the right decision.

Re:Worth Learning?

[j3110]

I'm going to attempt to answer this question, but it's not really easy.

The first thing you should think about is pre-J2EE history. Back before J2EE everyone was developing their own systems. They had their own persistance layer, their own distributed transaction system, their own network protocols in some situations. Was this system faster? Yes, of course it was. If you can develop your own system custom to your task, it's always going to be faster.

Performance was not the reason for J2EE. Scalability was not the reason for J2EE. They are part of a new push in the software world. Overall economics is where J2EE comes in. It's more expensive to create your own framework than to buy one. It's more expensive to train developers on how to use your framework than an existing standard. If you had one person developing just your infrastructure full time it would cost you 100K/y in salary, which is more expensive than the most expensive J2EE server will run you on average.

Now I would like you to think, "Why don't we write our own database systems?" If we write our own system we wouldn't need to parse SQL. We could store the data in relation formats where it's good, and hierachial where it makes more sense to be hierarchial. The system would be faster be a very significant amount.

The point is if you keep "reinventing the wheel" (I hate that phrase.) your competitors will beat you to market.

I think I've covered two of the main points here.
1) It can be cheaper
2) It can be quicker to market.

Who cares if it requires a cluster of Opterons to run, software has always cost more than mass produced silicon waffers.

So, back to the main answer, which by now you probably can see, when to use EJB.
1) If you need distributed transactions.
2) If you need platform independance. (.Net clause)
3) If it will let you get to market quicker.
4) If you need declaritive security checks.

If none of those ifs apply to your project, then you would be an idiot riding hype if you use EJB. As for my EJB projects, I can generally say I need all 4. You can't force Linux on clients because they don't have administrative people that will patch it like they do windows. You can't use windows because it isn't reliable as a server generally. Let them pick and live with their own decision is my philosophy.

Re:Worth Learning?

[pHDNgell]

Firstly I've written mod_caml which is, you'll be disappointed to know, an interface to the Apache API from Caml.

I'm a little confused by the point of this statement. Why am I disappointed to know this?

Secondly, OCaml isn't just a compiled language.

Well, no, it's got a repl, but that would seem to defeat the purpose of the static typing.

Thirdly, if you'd ever written a website you'd know that queries on the database dominate. Interpreted, compiled - it makes no difference.

You left out the word ``badly'' in the first sentence. Putting a lot of the work on the DB limits scalability dramatically. I had to deal with these issues at my current job. Everything that wanted data, no matter how static, would request it directly from the DB at the point it needed it. We had horrible scalability problems and couldn't get a DB server big enough to handle our load about a year ago. Now, with approximately 8-9 times more traffic, things are typically 12 times faster.

A well-written CGI will be less efficient than a well-written servlet, especially under load.

This is plainly wrong.

It's my experience, mostly due to the ability to pool and cache data, as well as perform asynchronous parallel processing even after the client disconnects, freeing resources for the next guy. It also helps to be able to perform a good deal of initialization before the first client talks to you and holding onto that state for a while rather than trying to figure out what to do every time a client makes a contact with you.

I mean, just from a syscall point of view, I don't have to fork/open/read/close/connect/close to figure out where my database is and connect to it. Not to mention the overhead of actually parsing the config and authenticating with the DB.

Why do you believe that a CGI is more efficient?

Does it tell you when NOT to use EJB?

[MillionthMonkey]

It's gotten to the point where people don't think you're doing "J2EE" if they don't see EJBs being used. If you don't need transaction isolation over a distributed system, EJB is overkill.

The infrastructure for those systems are hard to write. The whole point of EJB is to have as much underlying general purpose infrastructure as possible already written for you, so you can plug your ad-hoc business logic on top. This puts development of these systems in the reach of a greater number of developers. But if you can write it yourself, you'll be better off. You'll be in control of more of the code, and won't spend your time messing with tuning parameters and configuration files for someone else's code. One exception is a distributed transactional system where it simply gets to be too much for you to reach your deadline. The other is a system that might be integrated into a larger system like that, that is already based on EJB. (Or the customer might be requesting EJB, maybe for a good reason.)

I sat in on an interview once where we were explaining the architecture of a server product we sell, and the first thing out of the interviewee's mouth was "You don't use EJB? Oh I'm surprised- you should really be using EJB!" That killed the interview right there.

Bitter is right!

[Eros]

Does anyone else think that it is messed up to create one framework that is suppose to handle business logic AND database persistant objects?

Whatever happened to making frameworks that do one thing only and do it well?

Re:EJB is REALLY Bitter

[ihatesco]

very HUGE specifications and as hard to learn as UNIX. You have 1000's of choices which lead wayward programmers easily.

Well, I learned how to cope with UNIX with the following steps:

1. I have been tutored by a friend of mine in the basics of Unix (shell, processes, login, logout and using lynx so I was able to go on mailgate.org and see unix link there.
2. I began using it for stupid stuff everyday, websurfing (good old lynx), writing my shit and mail (pico and pine). When I began using pico I also gave up on using Microsoft Word.
3. Then I bought Redhat Linux 5.2, Unix for Dummies, and Linux for Dummies Expresso. Redhat had a very interesting manual at the time.
4. Most important stuff: usenet! usenet! usenet! Google for answers, post for (uncovered) questions.

I had a very funny time, but most important in 3 years I covered EVERYTHING meaningful about Unix to be able to use it as I use Windows... well... better than Windows :)

+ + + +
The differences between Unix and EJB are:

1. You are not obliged to learn EJB every day in order to use them like you would do if you were pushed to work on a Sparc Workstation and you had to read your mail through mutt.
2. Thanks to Free (Speech) Software like GNU/Linux distributions, or *BSDs, you may learn Unix as an hobby... fire up slackware, tune it and then play Wolfenstein (I remember when I set up my Radeon correctly under linux... I cried. The alternative at the time was Windows ME, which showed nice red dots with my Radeon)... EJB per se is only a mean to get a work done.
3. You need a really solid Java background, a really solid Object-Oriented programming Design background and some knowledge of the accompaigning technologies (sql/jdbc), something that you may learn only if you really focus on it, not as a "collateral effect" if you are on a workplace or college where the admins wants you to use vi, trn and mutt. On the other hand Unix needs you to know how to switch on the computer, and how to use a keyboard. Also, mastering Java and OOD is difficult _per_ _se_ (even if Java is easier than C++ in many regards).

The lot of choices are not the problem. The knowledges required to know them is. Unix is easier on the whole. Learn regexp and use them everywhere. Learn to decipher manpages (gnu info is worse in many regards to manpages) and again you can use them on any *IX system.

All IMHO and IME :)

Re:Languages need novices, novices need good books

[kfg]

Not just for novices. I'm a "graying ponytail." I cut my teeth in real programing on an IBM 360 in APL. Selectric as the i/o device. "Changable fonts" by changing the typeball and all that.

I'm hardly either command line nor dense mathmatical code shy.

Today I'm a bit of a C+Python snob, but I went through a VB phase when making the switch to graphical shell programing. It was like magic. It got me up on my feet and running, producing really usable apps in the Windows enviroment in no time flat.

I "outgrew" it in fairly short order, but as a stepping stone between "old world" and "new world" I found it invaluable.

KFG

Re:Languages need novices, novices need good books

[GOD_ALMIGHTY]

I'll give you that tools have been lacking in the Java Enterprise world. Most of the good ones allow experienced developers be more efficient, and few really give the novice programmer a leg up.

The biggest problem facing EJB and all of the major environments right now is not how easy it is to work in an environment, but how well the developer understands distributed components and n-tier architectures. Look at SOAP, I've worked on a couple of projects that involved SOAP, the most recent is a .NET client written by an offshore team and our in-house JBoss based J2EE app. We expose the EJBs via both local and remote interfaces to other Java apps and via SOAP to the .NET client.

The problem is that the .NET developers how no idea how to use inversion of control patterns for managing network connections and no idea how to use SOAP efficiently. They make common mistakes like unnecessary calls, which are expensive in SOAP and not caching data properly on the client.

Quite frankly, given the problems I've seen with this and other SOAP projects, I don't believe that SOAP offers any advantage over CORBA. The biggest claim SOAP has always had was that it was easier than CORBA, but what I've seen is that developers still have to learn distributed components and that was always the hard part of CORBA. Distributed component mistakes in SOAP become an order of magnitude more expensive than in CORBA due to the XML bloat and the processing power needed for serializing/deserializing SOAP.

This holds true for things like EJBs and other J2EE components (MBeans), if the developer does not understand the basic principles of distributed components, they will write a bad app. It doesn't matter the environment or how "easy" the tools make it for the novice, writing something other than garbage in this environment takes fundamental understanding of the problems involved, which is not covered in depth enough in most of the books and typically takes some experience.

That being said, learn distributed components and n-tier architecture. I'd recommend Java precisely because the complexity that the novice sees will hopefully allow them to see the causality while they learn distributed components. The patterns will start to emerge after a while. Then it won't matter what language or platform they use, they'll know how to write distributed components and the infrastrucure required to run them.

Once they learn these patterns, they can then use tools like XDoclet to quickly automate the tedium and repetitive bits needed to make the system work. Also, all the tools needed for learning this and building productions systems are available from the Open Source world (minus a JVM), so no vendor lock-in.

To summerize, I don't think it's the language they need to learn, it's distributed components and their infrastructure, the language won't teach them much.

Re:EJB is REALLY Bitter

[lokedhs]

In the EJB case, I agree that they are very complex. I've been developing EJB-based applications for several years now and one of the biggest problems for me is to explain the concept for newcomers, even if these newcomers are very good Java developers.

Unix is complex too. I'm not talking about using the shell or the GNOME desktop. I'm referring to learning how to develop a good application. Learning C well, and learning all the Unix system calls, what they do, proper error handling, and making sure that your application not only works on your specific Linux system but also on all other Unices that are out there. As it happens, these are the exact same problems that EJB developers struggle with.

With Windows (.NET components) there are much fewer problems since there is only one implementation and one company producing this implementation (and please don't mention Mono, they are playing the catchup game and Microsoft will never do anything that makes life easier for them or their developers, unless it also makes it easier for themselves).

With regards to Java in general I can't agree with you. Java is extremely easy to get into, and the only thing that can be difficult for C (and in many respects C++) programmers is to learn proper object oriented methologies. With some experience with other object oriented languages like Smalltalk or Python, learning Java is a matter of hours.

Re:The main mistake of EJB.

[Glock27]

They confused complexity with usefulness.

I wouldn't put it that way. It may be that Einstein's dictum of "make it as simple as possible, but no simpler" wasn't followed. That I'd accept as a valid criticism of some of Java and it's libraries.

A system with complex rules isn't necessarily more powerful, but it's usually more difficult and error prone.

I'm not sure what you mean by "with complex rules". The essence of the matter is that developers want to use complex libraries and subsystems, in the hope that they'll solve equally (or more) complex problems. EJB's (and J2EE's) success or failure should be judged in that light. This is also true with regard to your "error prone" comment. The exact attraction of the J2EE architecture is that it should remove both risk and fragility from the system by using robust, tested code. There is a very large test suite that must be passed in order for an application server to be J2EE compliant. I think very few that have deployed J2EE applications would characterize the environment as "fragile".

It certainly seems to have solved some need, because many projects are using it, many successfully. It certainly runs on the highest-end server hardware out there (up to over 100 processors in a single SMP box, which can be clustered).

Unfortunately this misconception is very common in computer science. People tend always to create complex APIs/infaces and protocols just to get a "powerful tools". The result is the security and error ridden state of the internet and computers we see these days.

First of all, J2EE systems haven't been the victim of many security exploits that I've heard of...Microsoft systems seem to be the usual victims. Both Unix and Java are Internet-hardened technologies that have stood up very well in real world use. Let's hear your alternatives now...

J2SE vs J2EE

[pong]

I think Sun divided their developers into two camps. One camp would make a virtual execution platform with a nice associated language and a good core framework and they labelled it java/J2SE. The other camp was given the task of designing an enterprise application framework and they labelled it J2EE. The big problem is that the J2EE team decided (and probably for a good reason) that everything should be dynamic and runtime configurable and pluggable and extensible to the level that it became so dynamic that the static typedness of java ended up being a big obstruction, which has led to complex code with a lot of declarations and layers that hide away your business logic.

J2EE really wanted to be implemented in ruby, or Python if that's your thing. it is so obvious.

J2EE is as ridiculous as the complete over-abuse of XML (Jelly and XSL comes to mind).

Prevayler solves a very specific kind of problem.

[rossifer]

Prevayler is a persistence golden hammer to those who have been converted. Here's an essay I wrote to add to the Prevayler wiki (but didn't have the permissions to add):

Without a more effective query semantic, prevalence will be limited to a very small subset of the problem space currently solved with O/R solutions.

The knowledge gap appears to be in the analysis of the value of SQL queries in programming and computational problem solving. My assertion: relational programming is actually different from object oriented programming and is more useful than OO for a number of problem types, including asking ad-hoc questions of the data set (very common for reporting, etc.).

This feeling, that SQL and RDBMS's are somehow a "throwback" or an "obsolete" technology reveals a lack of understanding of the relational programming model. This feeling has also led to a lot of "trips around the block" (Yet another OO database, etc.). OO databases don't really catch on for anything because they don't solve real world problems better than relational DB's. Yet time and time again, OO databases are trotted out as the "road to freedom from SQL". SQL, appropriately applied, isn't any more confining than Java or any other programming language, appropriately applied. Unless you take a close look at one of the problems that SQL solves elegantly, however, this statement will not make any sense to you.

Based on my experience, the biggest differences between the OO model and the Relational model include:

• The relational model is not encapsulated, which allows even unanticipated questions to be answered after the system is complete without substantial/any modification to the system.
• Relational optimizations (a.k.a. indexing) are the key to performant queries and the ability to simultaneously use more than one index (actually N) for query optimization has no useable analog in OO query programming (yes, you can maintain lists of lists on a per-query basis, but ouch!)
• Once you have several dozen indices speeding things up, index maintenance in RAM in OO is harder than for a well-designed RDBMS (PostgreSQL, etc.). Both slow down the creation of new objects, but:
  • RDBMS's use a number of "tricks" to minimize the cost of row insertion and effectively minimize the code development cost of that insertion from the developer.
  • The OO developer, on the other hand, must take the time to insert each new object into each sorted collection of objects, complicating code and consuming lots of time.

Basically, I accept the prevaylance performance numbers, simply because I can make any decent RDBMS perform queries 3000x to 9000x slower than nominal on a sufficiently large dataset by screwing around with the indices. What I don't accept is the claimed significance of your numbers. Who cares if your system is 9000x faster than Oracle + O/R for your carefully chosen example problem if my real world problem is 5x faster but requires 100% more java code and can't easily handle new report types? Most of the time, performance is one of the last aspects of a new system to get any attention, and IMHO, that's exactly the right emphasis for performance in system development.

Let's propose a real business application with dozens of objects in a complex model and then throw a few million instances at it. Now let's start adding queries to the system and let's see who does better? I'll bet that I don't have to try very hard to get the queries 1) written faster and 2) executing faster against the O/R layer than you do against the objects in RAM, but then since I'm choosing the dataset, you know that's not going to be too difficult :)

I'll freely admit that you guys have some really cool ideas, and I *really* like the idea for small apps that already use files for persistent state. Only problem is that none of the products I've worked on in the last ten years fit a mold that prevalence would make easier. If anything, your approach mak

Re:Good database design is still essential

[pmz]

But you first have to learn the basics of good database design, for without that, you are hosed.

Agreed. It is also easy to argue that doing the database design first in a project rather than slapping it together as classes are created is the best approach. Normalization is important, too. I've seen a database where some tables had over fifty columns, where there were blatant opportunities to split the tables up into much more logical entities. But the developers didn't do it, and the software suffers terribly as a result.

Re:EJB is REALLY Bitter

[metamatic]

One, for those who wish to develop components for use within the EJB framework, there is a small set of interfaces and objects.

And a completely different set of deployment descriptors for every single EJB container, meaning you can't take your EAR file developed for (say) JBoss and deploy it on WebSphere or BEA. That, to me, is one of the biggest problems with EJB--zero portability of the finished packaged code. Wasn't Java supposed to be 'write once run anywhere'?

Re:Languages need novices, novices need good books

[RevMike]

At least the novice developers can use it. Look at Visual Basic ... anyon[e] can pick it up and get started ... Now a large number of those first projects are garbage apps, but at least they give a starting point.

The idea of a novice picking up J2EE is fscking hilarious. J2EE is a framework for Enterprise applications. Almost by definition, these apps are outside the purview of a novice, at least without careful hand-holding by a guru.

Novices - using any language or environment - don't write applications with scalable components, a robust transactional system, a complex persistence mechanism, a high quality messge substrate, and a directory system.

One might as well complain that an F-15C air superiority fighter is inferior to a Cessna 172 because a beginner can fly a Cessna with very little training. If one needs to shoot down a Mig-29, the Cessna is not going to cut it. J2EE developers need to come to the environment after deveoping a sound foundation in other technologies, up to and including RMI and CORBA.

Why EJB is chosen

[rollingcalf]

Managers are seduced by the hype, and their observation that "everybody else is doing it", so they order EJB to be used in the company.

Programmers are seduced by the buzzwords, and want to be able to put EJB on their resume, so they will either actively encourage their management to choose EJB, or will use it for every imaginable task if it has already been chosen.

In reality, over 95% of EJB applications could have been developed cheaper and faster and with less bugs if they used Java without EJB. You can get scalability, clustering, and failover with servlets, without the tedium of EJB. You can get persistence with JDO or JDBC facades, with better performance and simpler than entity beans. You can get asynchronous messaging by using JMS without EJB. You can get remoteness using RMI without EJB.

But the reality doesn't matter. Both programmers and managers have been seduced by the hype and buzzwords, so EJB will live on even if it makes things ten times more difficult and expensive.