An early draft review of EJB 3.0 (JSR 220) has been released by the JCP.

The purpose of Enterprise JavaBeans (EJB) 3.0 is to improve the EJB architecture by reducing its complexity from the developer's point of view.

This review closes on 30 July 2004, so take a look and give your feedback to the expert group.

EJB 3.0 Early Draft Review

JSR 220: Enterprise JavaBeans 3.0 home page

Just a reminder that we are having an EJB 3.0 panel tonight (Wednesday) at 7:30pm at JavaOne, so now is a good time to read the spec (it's less than a hundred pages ;-)) and give us feedback tonight.

--
Cedric

...also, the JDO 2 BOF is Wed night @ 10:30 PM...

--matthew

I wrote tutorials and made conference about EJB and i'm very interested in EJB 3. From now, i think it's a great job that had been made.

I wanted to know if there is anyway to help :)
and to know if there will be a reference implementation, if so, who is making it ?

Cedric, why should we bother to show up? The EJB 3.0 groups seems hell-bent on doing whatever they feel, like re-inventing JSR-12/JDO. In fact, sitting in yesterday's EJB 3 architecture tech session and today's persistence tech session, it seems that Linda D. can't actually say JDO in front of a group. Somebody higher up in Sun needs to unite EJB 3.0 persistence and JDO. Justing picking Hibernate because it isn't JDO doesn't do anyone any good, save the massive egos at JBoss.

Cedric, why should we bother to show up? The EJB 3.0 groups seems hell-bent on doing whatever they feel, like re-inventing JSR-12/JDO. In fact, sitting in yesterday's EJB 3 architecture tech session and today's persistence tech session, it seems that Linda D. can't actually say JDO in front of a group. Somebody higher up in Sun needs to unite EJB 3.0 persistence and JDO. Justing picking Hibernate because it isn't JDO doesn't do anyone any good, save the massive egos at JBoss.

I don't think that is a fair statement at all.

If you look at EJB3 and JDO2, both of these have addressed problems that they probably wouldn't have in the absence of the other, and I know for a fact that JDO2 was accelerated by the EJB3 "impending fist of doom" ;-)

In other words, even though it would be nice to have 100% of the app developer technical challenges solved without any standards overlapping, what we're seeing here is several different standards and products (including Hibernate, judging by some of Gavin's comments) improving from the conversations that are occurring. That is how it _should_ work.

As for personal issues with Cedric, Linda, etc. .. well, Cedric is a bit hung up on the whole EJB/JDO thing for some reason :-p but he was talking to Patrick (CTO of Solarmetric, the company that makes KODO JDO) one night and Robin Roos (who just got hired by Solarmetric) on another occasion. We should afford these people the time to talk as civilised and intelligent contributors without trying to make this whole thing into a WWF wrestling match.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

You don't think that's fair? You are wrong. The fact that the EJB 3.0 expert group has been suckered by Hibernate and their FUD-ster JBoss paymasters is not indicative of a need for any "meaningful dialog". It is only indicitative that they have somehow managed to get themselves into a position where the only people on their expert group who know anything about persistence architectures are a group of self-proclaimed experts with shoddy solutions and a proven history of spreading lies and FUD about any other architecute that they don't have control over. The fact that the EJB 3.0 group has closed themselves off from any potential opposing viewpoint is a bizarre and irrational stance to take. It is not something to "talk as civilised and intelligent contributors": it is something to call what it is: sheer idiocy and technical incompetence.

The simple and irrefutable fact is: THE EJB 3.0 PERSISTENCE FRAMEWORK IS NOTHING BUT AN INFERIOR AND IMMATURE SUB-SET OF THE EXISTING JDO SPECIFICATION. Find me one thing in the EJB 3.0 persistence sections that is not already provided by the JDO 2.0 specification. One single thing. You can't? That's because there isn't one.

It is idiocy that Sun would spend years to get to a point where they have an official and mature persistence framework that is implemented by a dozen vendors and then fliply throw it away for some half-assed and immature clone that happens to be very similar to the flavor-of-the-month open-source solution (and written by a bunch of people that are PROVEN LIARS AND MANIPULATORS). This is not a decision that is made based on technical merits (there are none), or on market factors (JDO is already well-adopted in a very many places). It is a decision that was made from technical incompetence and being susceptible to the silvery tongues of greedy and dishonest people.

How's that for fair?

You don't think that's fair? You are wrong.

Hani, is that you?

--
Cedric

Nice flame.

Both Hybernate and JDO were started in ancient history. Both continue to evolve and learn. For sun to pick one of these as a main trend is fine, and to bring another perspective is fine.

Personally I love SQL, its open, available and usable. How great it would be if sun embraced that. Relational data is the heart of your business. Objects are tied to some momentary business application.

Jonathan

Doug Pierce :

Cedric, why should we bother to show up? The EJB 3.0 groups seems hell-bent on doing whatever they feel, like re-inventing JSR-12/JDO. In fact, sitting in yesterday's EJB 3 architecture tech session and today's persistence tech session, it seems that Linda D. can't actually say JDO in front of a group. Somebody higher up in Sun needs to unite EJB 3.0 persistence and JDO. Justing picking Hibernate because it isn't JDO doesn't do anyone any good, save the massive egos at JBoss.

I'm going to stick my neck out here and suggest that with all due respect, we need to de-escalate the emotion in the discourse.

I understand that people get frustrated, but people are frustrated on both sides, and the result of this escalating frustration is that people withdraw and the conversation stops. When the conversation stops, there's no chance for collaboration.

We now have two early draft specs to look at, one for JDO2 and one for EJB3. They can be found here :

http://jcp.org/aboutJava/communityprocess/edr/jsr220/index.html

http://jcp.org/en/jsr/detail?id=243

Go get them. Read them. Lets talk about the technology.

geir

I agree. These threads have become argumentative more frequently over the last year or so. Most of the participants seem intelligent, and thoughtful and yet somehow the understanding that resolution stems from engagement rather than.. fill in the blank here, but certainly - aggression - has been lost. Maybe we're all unintentionally reacting to the increasing violence of our world, but as someone who knows far less than most of you, as someone who was attracted to this site for your insight, I'd very much look forward to returning to the inquisitive discussion of "yore" rather than continuing down this path of the blind, deaf and loud.

Cedric, why should we bother to show up? The EJB 3.0 groups seems hell-bent on doing whatever they feel, like re-inventing JSR-12/JDO. In fact, sitting in yesterday's EJB 3 architecture tech session and today's persistence tech session, it seems that Linda D. can't actually say JDO in front of a group. Somebody higher up in Sun needs to unite EJB 3.0 persistence and JDO. Justing picking Hibernate because it isn't JDO doesn't do anyone any good, save the massive egos at JBoss.

The fact that the EJB 3.0 expert group has been suckered by Hibernate and their FUD-ster JBoss paymasters is not indicative of a need for any "meaningful dialog".

You guys should consider reading this early draft spec, there are lots of goods stuffs in there. *I* did read it, and no, this is not a simple copy/pastle of Hibernate, neither IoC containers. Give technical feedbacks to the EJB3 EG to make the component / persistent technology easy-of-use(tm) into J2EE 5.0 ( can't wait for J5EE 13.0 ;-) )
Make it technical guys

Emmanuel

Cedric, why should we bother to show up? The EJB 3.0 groups seems hell-bent on doing whatever they feel, like re-inventing JSR-12/JDO. In fact, sitting in yesterday's EJB 3 architecture tech session and today's persistence tech session, it seems that Linda D. can't actually say JDO in front of a group. Somebody higher up in Sun needs to unite EJB 3.0 persistence and JDO. Justing picking Hibernate because it isn't JDO doesn't do anyone any good, save the massive egos at JBoss.

What do you think they should have picked? Non-existent JDO spec?

If I had to choose between proven product with nearly 300 000 downloads or an idea of something that might solve all the problems beneath the sky in some point of future, decision would be easy.

And there is nothing stopping you from using JDO version Future with EJBs if you want.

IMHO, I feel they should have picked none. I would prefer they define a minimal interface for a service provider and let those vendors compete on a service leve.

First, let me say that I don't really have a religous leaning either way. My *problem* is driven by business concerns and the fact Sun hasn't stepped in and said that we shouldn't have two competing transparent persistence standards for data objects. In my brief conversations with Sun people on both side, it seems that this is a sore point, as it should be. Honestly, I don't care about the exact outcome of any standardization between the two groups; but there should be a single standard. The glaring issue I saw is that Linda seemed to go way out of her way to not mention JDO, and to hammer on relational database mapping. JDO2 has standardized ORM, but there is a *lot* of fud coming out of EJB side about JDO and bytecode enhancement. I would be perfectly happy if Jonathan Schwartz or someone stepped in and said that there will only be one official standard for transparent persistence. EJB is much bigger than just transparent persistence; JDO is a standard for transparent persistence. The two are not mutually exclusive, and I feel that all users and software developers would win if there was a single standard for transparent persistence, whatever that standard is.

Doug

JDO2 has standardized ORM, but there is a *lot* of fud coming out of EJB side about JDO and bytecode enhancement.

Just for the record, one of the primary goals of JDO 2 was to open the door for proxy-based and reflection-based implementations. Enhancement is no longer the only viable approach. (Enhancement was never technically required, but in JDO 1 it was hard to build a good implementation without it.)

I totally agree with Doug and really don't understand why these two standard did not merge to a single one yet although they both came out quite a long time ago and both had to emerge a lot from their very first versions. It's really strange: I am giving EJB courses now for more than two years and when ever it comes to talking about persistence management I must recommend not to rely on one of the standards at all. As long as there are two different ones, there is in fact none at all, because there is a fifty-fifty chance for both to disappear or for both to change a lot to meet the other someday. So for the time being it is actually the safest way to use an *independend* persistence manager. And something which is very close to SQL because this is the only standard you can probably rely on for the next 5 million years. This is why we put our own one OpenSource a year ago. It's a petty but it's pragmatical. And pragmatism is what counts to me, because I don't want to make religoin but software ;-)

I totally agree. ejb should delegate persistence to jdo,
which is the java api to persist objects. We have jdo for persistence,
jaxb for xml binding, jax-rpc for xml remote call, etc, ... so ejb
should be about how to weave all these api together as services for
user classes. So ejb should be about how ioc and aop find their way
into the java platform, and as such, it should target all platform,
jm2e, j2se, j2ee.

Any dates on when the final release would be out?

I've had a look at the spec and found interesting simplifications (no need to define interface anymore, entity bean simplification, ...)

However, I get the feeling that EJB moves away from the component model: one of the software component's characteristics is that "a component is customizable without modification of the source code". With EJB, behavior that was once specified in the deployement descriptor (that was thus modifiable without touching source code or recompiling) is now specified in annotations. What if you want to reuse a bean, but with different authorization behavior ? If you rely on annotations only, you're dead.

Annotations are cool when they allow you to specify structural information about your code (this method is part of the interface, this class represents a stateless bean, this method should be web service enabled) but imho they are evil when they specify how your code should behave. OK it's faster, but it reduces your adaptability. Remember that one of EJB's goals was to define portable, reusable, and adaptable components. Deployment descriptor may be complex, but they were introduced as a mean to tune your bean's behaviour without touching .java or .class

Same goes for entity beans, I hate to see OR mapping informations in source code, it's not where it fits. Entity beans are domain objects and should not be concerned about how they will be persisted (if I remember well it's the persistence manager's job) Defining column names in your object source may be faster, but it locks you in a particular schema, and prevents you from adapting to any existing schema (it does happen, only think of customer user table that have same logical structure, but different naming conventions) That's why I always prefered to use hbm.xml over xdoclet when working with Hibernate, even if the latter is faster and might be more convenient while developing.

I'd conclude by saying that one must not always avoid complexity at all cost, sometimes a bit of extra complexity adds real value.

My two cents.

Gavin,

Your statement: No DTO's

So each time when creating instance of entity it's exposed remotly as well?

Because if not I don't get it how you can get rid of dto's in other case. If my domain model has "big" 1-m association I do not want to transfer half of database to the UI. It would be mouch better to transfer just "domain view" to UI not whole picture. So I do not agree that EJB 3.0 spec will help me to get rid of DTO's.

Especially those numbered 1-4. However, patterns help to overcome
traditional OO as applied to EJB2 and once you have solved these
problems you mention, you are now in a development position to
realize ROI. My personal opinion is that, web-centric applications
without a need for Enterprise business logic sharing and re-use,
were denied a J2EE o/r mapping solution, without using the steepest
of the EJB learning curves, Entity beans 2.0. Since most of J2EE
applications are web-centric, with reusable Enterprise business components
across many clients and applications just starting to make its way
into the enterprise mainstream, a O/R mapping solution was needed
to support these web-only apps. Now JDO or Hibernate could be used,
BUT, they are not J2EE standard APIs. I disagree with the statement
to stay with SQL. While SQL might be better for some skill sets,
it is O/r mapping that will show the ROI and is better for the business,
not the skillset.

You are going in the right direction. Congratulations in getting this out to the community in a timely manner.

Thanks

Congrats on getting the EDR out the door. I'm looking forward to digesting it, and am hopeful that we (the Java data persistence community) can establish a... umm... cordial collaboration to make Java *the* place to be for data persistence.

-Patrick

--
Patrick Linskey
SolarMetric Inc.

I must admit I'm a bit puzzled right now. With this draft out, I don't see anyone doing any new EJB development. Why would I start any development with EJB 2.0 now when Servlet/RPC/Hibernate solution seems to be much closer and easier to port to EJB 3.0 then 2.0 -> 3.0? And if I develop a solution sans EJB, will I really have incentive to port it? Anyone else doing it, but Sun itself, I'd call this spreading FUD. (otoh, some would say that it's not possible to spread more FUD about EJBs, as it's already so covered in it, no one would ever notice :P)

I do agree that "and now something completely different" can be fun, especially when doing "the good thing", but I can't really see where it fits in the (E)nterprise part of (E)JB, people that use standards because they feel standards are something safe, evolves slowly and doesn't jump around like a rabid monkey. Can you imagine all the PHBs and MBA drones going berzerk, when Dilbert explains them what this means? Hell, can you imagine Dilberts reaction?

Despite the recent similarities between TheServerSide and JDOCentral, I think I'll go against the grain here and congratulate the EJB3 EG for getting out the draft for early review.

The spec is concise, clearly written and has the potential to completely reinvigorate server side persistence and component development. The biggest challenge I see ahead is the number of EJB 2.1 developers frothing at the mouth waiting for implementations to appear.

I really like the idea of component annotation names which are reduced to their concept (like @Stateless) rather than depending on the actual technology (e.g. something like @EJBStatelessSessionBean). I am working in the CUBA project which provides a litte framework for the development of components which can be run as EJBs, AXIS webservices or in stand-alone application. Not just for testing, as it is often mentioned in the EJB 3.0 draft, but also for *productive* use (check out http://cuba.sourgeforge.net if you like).

EJB's new annotation approach perfectly fits to our concept of being functionally equivalent to the EJB model on one side and to support different runtime environments on the other. Write your components once and don't bother if you will actually run them in a full-fledged J2EE application server. Light-weighted, technology-independent annotations would allow us to incorporate the same ones in our framework.

I'd like to take this opportunity and encourage the EJB 3.0 specification team to keep this idea up.

I took glimpse of the EJB3.0 specification. I always disliked EJB because it had got its own

1)Complex learning curve.
2)OOP-killer,can't use much of OOP in EJB's.
3)Confusion about Local or remote confusions.Then having both local and remote interface duplicating code.
4)Half baked query in deployment descriptor,persistence suuport with CMP.
5)Write wrapper in the framework so that the non-EJB component can be reused in a App server environment.
6)Reinventing the old java application completely just to make them EJB-compliant.

Recently after using JDO,I became die hard fan of its persistence mechanism.Simple POJO(plain old java objects) doing

persistence so well that in EJB,it took lot complexity to achieve.

With JDO,you can break the complete subsystem into granular POJO and can move them from web to data tier and persist them,so easy life :).With EJB3.0,you will find some similarties,if you are coming from JDO/Hibernate world.

In brief about EJB3.0 ...
1)No need of Home interface :) (No need ).
Just say new() ,you get an "instance"

2)No more confusions to make an EJB remote or local,it's the client which would decide and cast to appropriate.

3)Just write SINGLE simple Java class and annotate it to be Stateless/Stateful/Entity/MessageDriven.Container

would generate or take care rest of the complexity on your behalf.

4)Use "annotation" and your POJO is ready to be used as an EJB. (Life is so simple,after coming back from complexity)

5)Any POJI(Plain Old Java Interface) can be your EJB interface,just use "annotation".

6)Entity Bean are now any POJO entity ready to persit in data store(it has to be a JavaBeans type). Use OOPs ...inheritence,association,everything is possible with Entity bean now.

7)Forget all EJB life cycles.For example Entity bean life cycle in 3.0 is new,managed,detached,removed.

8)Heard of dependecy injection in Spring,HIvernate,HiveMind ? They are great and they are the way for Enterprise application. Now it's part of EJB3.0

9)Ready to develop complex query,inner/outer join with EJB3.0.

10)Lastly unlearn all EJB skill and get on a fresh mind for 3.0.

Time for somebody to write a "Never Mind changing EJB" book.:) ?

I was told when voicing astonishment at losing CMR, that many
folks are successful with EJB2 persistence, and that it will continue
to be supported, and that I should stay with it if I'm happy with it.
I was also told that some of the EJB3 features can be applied to your
EJB 2.0 domain model implementation. This begs the question - Will
there continue to be work on the EJB2.0 persistence model, as well
as EJB3.0? I guess only time will tell whether it is worth it to
migrate from ejb2 to 3.