Overall, while there are some much-needed enhancements such as bulk update and bulkdelete operations in EJB-QL, it looks like the committee has chosen to emphasise backwards-compatibility over clean design, and have therefore approached the complexity problem witha wallpaper strategy: “Give developers a simpler programming interface, but don't mess withwhat's underneath.” We find this approach disappointing, because the problems with EJB runfar deeper, yet are very fixable. We think this draft is more like an “EJB 2.2” specification, because it defines little more thana wrapper around the old model. Whether one employs XDoclet's mongrel approach orannotations with a JSR 175 pedigree, it's still nothing more than a workaround, because thecore architectural issues of that model remain unaddressed. A true “3.0” spec should be boldenough to confront these architectural issues and fix them, even if it breaks backwards-compatibility with older applications.