Everyone and their dog has an opinion on the EJB 3.0 draft specification. Another article has been published, which goes into some detail on the specification, and what it means for us. The author also has a few opinions on some of the issues too.

Opinions

EJB 3.0 is surely a job well done, and the expert group deserves all the praise for a wonderful effort towards making the life of an EJB programmer easier. With that said, life will be easier, but surely not easy, with more than 50 annotations already defined (several more expected in the next draft), each with its own set of rules for defaults and other behavioral specifications. Of course, I wasn't really expecting an "EJB 3.0 = EJB 2.1 for dummies" kind of equation. Still, I would like to express my humble opinion about a few issues:

• For one, the specification has surely made iterative development easier with fewer program artifacts, intuitive defaults, and a simpler model for access to the runtime environment. I also like the fact that the home interface is gone, which means fewer artifacts to even visualize.
• In earlier EJB specifications, entity beans used to be a view into the persistent store. It was theoretically (and probably only theoretically) possible to map an entity bean to any legacy EIS (enterprise information system) also. Doing so was accomplished with longer-term extensibility in mind and was meant to allow wider adoption of entity beans for business data modeling. Instead, the accompanying complexity only hurt the prospects of entity beans. As proposed in this draft, an entity bean is just a view into the database. Life is much simpler with no abstract persistent schemas and a simpler data-access model.
• While I warmly welcome the above change, I'm not comfortable with the idea of having SQL snippets in EJB code (annotations). Some developers are totally against even the apparent "SQLness" of annotations (like @Table and @Column annotations). In my opinion, this "SQLness" is okay—after all, we are clear that we are talking about databases. But SQL snippets like columnDefinition="BLOB NOT NULL" make me really nervous because such an approach encourages a tight coupling between EJB code/annotations and SQL representation of the same.
• Though support for native SQL queries appears tempting, embedding SQL in EJB code is a very, very bad idea. Of course there are ways to avoid hard-coding your SQLs, but those approaches would serve better as part of the specification, rather than individual developers' custom patterns.
• I assume that use of annotations like @Table is only declarative in the bean class. The table name specified through the name member of the @Table annotation will probably have to be mapped to actual database tables at deployment time. The specification should be explicit on this issue and prescribe a consistent model.
• The specification also needs to be more explicit about changes to the client-programming model, particularly standalone Java clients. All references to the client-programming model in the draft have implicitly assumed EJB clients. The draft also fails to touch on the issue of backward compatibility for client programs.
• he Transient annotation should probably be renamed to avoid conflict if it is used in place of the transient keyword. In fact, on this issue, I believe we should be willing to deviate slightly from the configuration-by-exception approach and define an @Persistent annotation to explicitly mark all persistent fields. The @Persistent annotation could be just a marker annotation or it could have a few annotation members to possibly associate with O/R mapping annotations.

EJB 3: An overview and critical analysis of the latest EJB specification

Everyone has an opinion - and so mine is the entire process needs to be reconsidered from end to end, not just the replacement of Entity beans with Hibernate persistence.

EJBs are way to freak'in hard to build, and even harder to test. Until these issues are addressed, I don't see companies continuing to pour money into J2EE custom apps. It's cheaper to just go .NET if you don't need platform independence.

I disagree, EJB solves a difficult problem of distrubuted components with security and transactions. It also allows vendors to provide non function requirement via their containers i.e. High Availiablity, Scaliablity and sometimes even preformance.

If you don't require this complexity because you app is simple, then Java has some simple persistent frameworks that will happly compete with .NET. And will be Free.

my 2 cents.

"EJB solves a difficult problem of distrubuted components with security and transactions. "

Or rather EJB creates the problem of distrubuted components with security and transactions.

It is however much simpler to simply not distribute your object model i.e. to follow martin fowlers first law of distributed objects: "dont distribute your objects".

I must say I disliked the idea of dumping SQL into annotations when I first saw it suggested at TSSS, and I still don't like the idea of specifying SQL in code that uses container managed persistence.
I mean what is the point of having CMP if you're going to write the SQL? Where is the time saving or portability?
Saying that you can "choose not to use" the messy feature is a bad idea in any spec, because people WILL use it and use and abuse annotations to hold all manner of garbage. I would think that if there is a need to write SQL, then use BMP and write the SQL, not hide it in a mess of annotations. What happens when you want to use your EJB in a database already containing the table that you specified? What do you do then: you have to change the code, recompile and produce a new EJB, rather than just tweaking a field in an xml DD.
I think the whole idea of EJB persistence is being butchered to cater for those who do not want a container come up with the same old simple select, insert and update statements that a child could write. They seem to be the same people singing the praises of any "lightweight" persistence mechanism that removes the need to write SQL?
My thoughts:

• simplify the overall object model (one class with annotations should do nicely)
• Don't let people put SQL throughout the (now) supposedly plain old java object, that's going to get oh-so-messy. It'll tie the code into a very specific database schema and place a range of hidden constraints on the "POJO" that you'll be writing
• if testability is the issue, then the SQL embedded in annotations is going to need a container to test or else something that rips it out of the annotations and pieces it together, rather than perhaps adopting a POJO combined with SQL code in a DAO which should be able to be tested independently.
• Perhaps create a simple SQL running utility class as part of the API to simplify BMP open-run sql-close type code? (If being able to write SQL queries simply is the real goal).

just a few thoughts, as I'm a little scared that EJB3.0 might be the point at which the spec goes into meltdown to allow those simple SQL statements to be placed all over the place, Nathan Lee

EJB 3.0 persistence is intended to be an object relational mapping so any dependence on SQL is quite all right. There will be an optional XML deployment descriptor if you would rather specify your O/R mapping separate from your objects. Many developers though like annotations (hence the popularity of XDoclet). A mixture of annotations and XML could clearly define developer intent via annotations and leave vendor and different database mappings in XML.

Bill

EJB 3.0 persistence is intended to be an object relational mapping so any dependence on SQL is quite all right. There will be an optional XML deployment descriptor if you would rather specify your O/R mapping separate from your objects. Many developers though like annotations (hence the popularity of XDoclet). A mixture of annotations and XML could clearly define developer intent via annotations and leave vendor and different database mappings in XML.Bill

Hearing you makes me give one more chance to Rolf. He may be right when he says EJB sucks and will suck for life.

A mixture of annotations and XML

We get rid of deployment descriptors by replacing them with deploymnet descriptors and annotations ?

I agree with dion almaar.

The early specifications atleast had the loosely coupled model
between entity abstraction and business logic by means of contatiner
managed persistence.

With 3.0 annotations the idea of defining @Table is not acceptable
in the bean class. what we are trying to do is having a coupled model.
and the idea of DAO Pattern completely goes for a toss.The DAO pattern
supposed to be an alternative of entity beans hides the actual
persistence layer schema from the process work flow .

Though the specifications has come with some useful innovations it is
neccessary to look into the mappings of CMP with annotations.

These anotations really bother me. It seems to me we are changing the whole language to do something a tool can. The XDoclet approach works, it's open source, it didn't require any language modifications so why do we suddenly need to build its functionality into the language. If we choose not to use xdoclet and stick with dds surely the tool providers can give us meshed view of a the bean and its dd, it could feel like you are editing one file when you are doing two.

With weblogic, I'm not sure about the other App servers, you have to have weblogic specific deployment descriptor so even if you use annotations you still have to do work in an external file (Please dont tell me we are going to have weblogic specific annotations!!!! ).

I know we are going to have the option of using dds or annotations but do we really need two ways to do it?

I think these anotations also mess up the whole pojo principal. Once you add them you can't call it a plain old java object cause its not it's an annotated pojo with all sorts of server related information in it.

From my experience of Using EJB's configuring them in XML dd's was not the biggest issue. Once IDEA started supporting EJB's I can't remember ever making the kind of silly mistakes that annotations seem to be addressing.

The things that bugged me most was the conversion of data between entity beans and DTOs. Thats why I moved off Entity EJB's onto a hibernate solution. Hibernate was configured in XML files, sure I made errors in those files but they were not the kind that annotations are going to solve. What I want is for EJB to give me stuff I can return to my client code without modification and Im not that keen on sharing annotated beans with my JSP developers.


Carl Marais

These anotations really bother me. It seems to me we are changing the whole language to do something a tool can. The XDoclet approach works, it's open source, it didn't require any language modifications so why do we suddenly need to build its functionality into the language.

a) code generation sucks. With EJB3 (and jboss at least) there is no precompilation needed if you use annotations.

b) xdoclet suffered from not being typesafe. Annotations give a compiler check for metadata, something that xdoclet cannot do.

c) Ever try to implement anything using xdoclet? It sucks ass....

 If we choose not to use xdoclet and stick with dds surely the tool providers can give us meshed view of a the bean and its dd, it could feel like you are editing one file when you are doing two. With weblogic, I'm not sure about the other App servers, you have to have weblogic specific deployment descriptor so even if you use annotations you still have to do work in an external file (Please dont tell me we are going to have weblogic specific annotations!!!! ).I know we are going to have the option of using dds or annotations but do we really need two ways to do it? I think these anotations also mess up the whole pojo principal. Once you add them you can't call it a plain old java object cause its not it's an annotated pojo with all sorts of server related information in it.From my experience of Using EJB's configuring them in XML dd's was not the biggest issue.

So, since EJB3 can either provide annotations or you can use a DD, what's your problem? If you use a DD, then your pojos look exactly like pojos and the EJB metadata is defined in XML. If you like annotations, then use annotations.

 Once IDEA started supporting EJB's I can't remember ever making the kind of silly mistakes that annotations seem to be addressing. The things that bugged me most was the conversion of data between entity beans and DTOs. Thats why I moved off Entity EJB's onto a hibernate solution. Hibernate was configured in XML files, sure I made errors in those files but they were not the kind that annotations are going to solve. What I want is for EJB to give me stuff I can return to my client code without modification and Im not that keen on sharing annotated beans with my JSP developers.Carl Marais

EJB3 persistence is very close to the Hibernate model so it will be a breeze for you to convert if you so desire (or a markitect forces you to switch ;-0 ).

Again, since annotations will be optional in EJB3, does this alleviate your issues here?

Bill

Mybe the EJB 3.0 expert panel needs someone who isn't an expert to give a bit of a reality check.

Mybe the EJB 3.0 expert panel needs someone who isn't an expert to give a bit of a reality check.

It sounds to me that Annotations reduce the diginity of a language to the level of a 'dialect'. It means the begining of the end for the language.

First, a quick disclamer. I am in no way associated with JBoss, Hibernate, or the EJB 3.0 team. I'm just a developer out here looking for technology that will get the job done without making my life hell.

Someone mentioned earlyer in this thread that we need a reality check. So here is mine. Annotations sound great. Why not just XDoclet? Well, I'll be honest, I have never used XDoclet, and I dont intend to start. Bill had it right. Code gen sucks. The last thing I need is another tool that is going to generate more code that is spacific to my applicaiton, that I dont control. Annotations seem like a perfect answer. Annotated bean are still as POJO as any thing else. As I understand the annotations specification, they are there to provide hints basicly. Wether you code uses those hints is completely up to you. If annotations make code non-POJP, the so does XDoclet. @Table SHOULD contain the actual DB table name. Likewise, @Column should be the name of a column, and @Schema should be the schema name. I dont need the annotation to just simply point to a reference that I am going to have to explain in another document. This amount of "SQLness" is perfectly acceptable. The only SQL that has no place outside the database is vendor spacific SQL. Every major RDBMS vendor in some way or another supports the idea of schema.table. The container should ahve no problem in figuring out how to use those annotations for any RDBMS. If you do for some reason switch db backends, you can, and most likely would maintain the same basic data structure down to the column and table name. Sure now the argument is "but what about non-rdbms backends?". The vast majority of EJB use has been with RDBMS. I fully believe that we get much more benifit from strongly tieing EJB to RDBMS that we loose.

What I'm getting at is, all I really want is a persistance framework that does what I need it to do, and dosn't get in my way by forcing me to address features I don't use. I dont want to have to code 3 to 5 classes for every freeking bean. I dont want to then have to go describe the damb thing in yet another document. I dont want to be forced to use DTOs. EJB should not be a "view into my database" it should be a representation of my data in my application that I CAN CONTROL.

So far the closest I have come to finding something that meets my needs is Hibernate. So far, EJB 3.0 looks alot like Hibernate, and I hope it stays that way. The only things I dont like about Hibernate are that it still requires descriptor documents, and its not backed by a standard or any major J2EE vendors (no, I dont count JBoss). EJB 3.0 will fix both of these.