@Target(TYPE) @Retention(RUNTIME)
public @interface Stateful {
  String name() default "";
  TransactionManagementType transactionManagement()
  default CONTAINER;
}

I’m not convinced that a normal Java/J2EE developer is going to be comfortable annotating his/her code. It will probably take time getting used to (as with anything). My worry is that you normally would not change enterprise programming models to such an extent. This is not what enterprise software is about. XML descriptors are not out, but you could choose a middle path by reducing the number of required elements in the XML descriptors and having the EJB Container infer these/choose defaults based on (non-annotated) code.

The draft specification also looks like it is addressing a problem space it does not own. Namely: the lack of proper tools that manipulate EJBs as first-class citizens (components) rather than as disparate pieces (bean class, home interface, remotable/local interface, XML descriptors). This is probably why the specification requires a J2EE Application Developer to declare his bean class alongwith numerous annotations and then at deploy/runtime generate all the artifacts mentioned above (home interface, remotable/local interface, deployment descriptor settings, stubs, skeletons etc). The idea is not a bad one, except that I feel it is not the specification’s responsibility to do this. Would you embark on a enterprise scale ASP.NET project and use wordpad/notepad to write all of your code? JBuilder does a pretty good job of abstracting away all the disparate pieces and treating an EJB as a component in its EJB Designer. And you want to use a Java development tool that does at least that.

The draft specification also does not require a J2EE application developer to explicitly declare an interface as being a remotable one. Everything is a Plain Old Java Object (POJO). In my opinion, a bad idea. Often declaring an interface to be an explicitly remotable one is not necessarily a bad thing. Especially in a medium/large development team where many members may not realize that they’re manipulating an object reference as a local one when in reality all calls are being dispatched to a remote server. Location over-transparency? Other technologies require you to explicitly declare an interface as being remotable - example: RMI requires it, CORBA requires it, .NET Remoting requires it (afaik), so why move away from common practise?

A plain daft goal of the draft specification is: testability outside of the (EJB) Container. What does this mean? If we take a look at the most popular testing framework for Java code out there, it is junit. JUnit is such a basic framework that you start wondering how you’d test an enterprise application outside of a Container that provides all services essential for an enterprise class application. Err, I might as well say - I have a database driven application that I want to test without a database. 

In the draft specification, it also seems like an entity bean is a data transfer object (or value object) is an entity bean. There is ‘detached’ model and a ‘managed’ model for entity beans when they are used by code in a (remote) client and code inside a container respectively. Often, applying basic modeling concepts tell you that you want to reduce coupling. But in this case, we’re encouraging client applications to access our domain/persistence model directly - albeit in a ‘detached’ mode with outstanding changes to be resolved back later (managed mode). I do not like this idea of blurring of lines between what consitutes your persistence object and what consitutes data objects (that are passed between tiers). And would you want to couple your client applications to your domain model?

On a related note, entity beans also expose a number of lifecycle methods to the developer. That is, apart from the EJB Container deciding when to read data from the database and when to write data (depending on transaction boundaries), the developer can choose to control these by calling the lifecycle methods explicitly. This might not be a good thing and might even encourage developers to start thinking about lower abstraction levels and mixing them up with business logic abstractions. Well, if we’re going to think and control many aspects we might as well go all the way and write our own EJB Container in the meantime These might also interfere with the different transaction commit options and caching decisions that can be specified for entity EJBs (pure deployment descriptor entries and therefore no touching of code required).

The draft specification also introduces the notion of Named Queries that can be specified as: