Found this gem on something called Soft Security.

I quote: "Not the same as weak security. The idea is to protect the system and its users from harm, in gentle and unobtrusive ways."Some ideas.

• AuditTrail. An audit trail tells you who did what, when. It doesn't necessarily allow you to undo what they did. It does let you know who was responsible.

• ReversibleChange. If anything that can be done, can be undone, no damage need be permanent. Version control is one way of making changes reversible. You can reverse a change without knowing who made it originally.

The wiki has a wealth of ideas, however I just wanted to highlight the ones relevant to Eclipse.  The wonderful thing about Eclipse is that it remembers every thing you did, and if you need to back out of a change it gives you a way to compare your changes against the history of changes.  Couple that with refactoring support and good JUnit tests and you've got one solid safety net that believe it or not, makes life less stressful.  Now, you might say that you already have this with a nice version control, however its not the same thing as having your own local history mechanism.  Its a concept modified from the original Envy version control system (arguably the only version control system I know that got it right), in Envy you had something called scratch editions as different from versions.  You need these scratch editions because you don't want to overly pollute your vcs with all your work in progress stuff.

Soft Security wiki also tells me why there's still a lot more a work that needs to be done after you persist your object model into a database. See that's the current J2EE programming model, as alluded to in Sean Neville's interview: "J2EE's policy is heavily oriented toward how to pump data into and out of relational databases in the most secure, scalable, managable way".  If you think, that's all there is about building applications, then J2EE is good enough.  However, if you want to build on  the ideas of Soft Security, that is taking your implementation to the next level (just like Eclipse took IDEs to the next level) then you've got to have something more powerful, EJB simply isn't going to cut the mustard simply because its too complex.

Why then is EJB too complex?  That's because EJB tries to satisfy multiple cross cutting concerns with an inadequate abstraction mechanism.  What that means is that it tries to merge resource sharing, transaction demarcation, persistence, reusable objects and a whole lot of other concerns using non AOP based technologies.  Now that we all know what AOP is about, we have some idea of how to weave together cross cutting concerns, however the EJB guys didn't have that luxury.   So, its pretty plain simple, without AOP, EJB is going to be a plain monster (i.e. Frankenstein) to deal with.

In summary, if you're content with "pumping data into and out of relational databases", then EJB is good enough.  However, if you're looking to build the next killer app without conscripting an army of programmers, then you've got to look at AOP.