The JCP Executive Committee approved the JDO 2.0 Public Review Reconsideration Ballot with 12 in favour, IBM, Oracle, and JBoss abstaining, and Apple not voting, a major sway compared to 10 of the same companies voting "no" during the last ballot. The existing JDO community will be supported, and we should expect to see a 2.1 release in the near term that outlines migration to EJB 3. Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java.

The passing of this ballot means that the JDO 2 expert group has received approval to continue with work on JSR243, including delivery of a Reference Implementation and a Technology Compatibility Kit. Existing JDO implementations will upgrade to JDO 2 and JDO users will have a temporary upgrade path. For those of you that want to read about the spec before posting about it, you can get a copy of it at http://jcp.org/aboutJava/communityprocess/pr/jsr243/index2.html.

Interestingly, very little has technically changed with the new draft submission. What resulted in the sway was a reclarification of the intention to "merge" into the EJB 3 persistence API, intense lobbying from various people in the community to the JCP EC committee, and a brief new preface in the new JDO draft which states that JDO 2 intended to meet the immediate needs of the JDO community and cannot exlicitly refer to EJB 3 since JSR 220 (EJB 3) isn't final yet, but that work has been done to make JDO QL work with EJB 3.

In the recent ballot, Sun, Google, Doug Lea, IONA, HP, Borland, Fujitsu voted to continue JDO, with no comments posted.

BEA voted Yes concluding that:

After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved.

Intel voted yes stating:

An agreement between the Spec Leads of 2 Expert Groups is not binding on the Executive Committee. That said, the extra time for review has demonstrated that the JSR 243 Public Draft is consistent with the "letter" from the Spec Leads so there is no problem there in any case. In similar situations in the future, it would be better to use the usual process of initiating a new JSR rather than a letter from Spec Leads. That would provide more transparency and involvement of the community.

Apache Software Foundation voted Yes saying "Let a thousand flowers bloom :)", a reference to their previous ballot vote where Apache said "Let the market decide."

Nortel voted yes and mentioned they "support the JDO Technology and its ongoing use."

SAP voted yes indicating that:

SAP thanks the JSR 220 and JSR 243 Spec Leads for the additional clarifications that were provided for this reconsideration ballot. We are satisfied with the clarifications regarding the future roadmap of EJB 3, JDO 2 and the new J2SE persistence model that is being developed as part of JSR 220 and therefore do not see an impediment for JDO 2 to proceed. Given that JSR 220 has the challenging goal to deliver an overarching persistence strategy for Java, it is important that the interests of all existing persistence communities, including JDO, are equally represented in this Expert Group.

Among the companies most vocallly opposed during the previous ballot, IBM, Oracle and JBoss voted to abstain this time, IBM abstained with no comment, and Oracle abstaining with the statement:

Oracle's primary concern has been partially addressed with the FAQ published by Sun reiterating that JSR 220 is the intended standard Java persistence API moving forward. Given the clear direction set by Sun on this issue, we will not object to the evolution of the specification to serve the existing JDO community. It is vital that the persistence work in JSR 220/EJB 3.0 for the mainstream J2EE community not be disrupted. EGB 3.0 is making excellent progress as part of the umbrella J2EE 5.0 specification and has been well received.

JBoss, which in 2003 supported JDO, grudgingly abstained with the comment:

Since this newly proposed specification is essentially identical to the one proposed during the Public Review Ballot vote, we would see no reason to change our vote, hence our previous comment remains.

However, while this vote is fundamentally a NO vote, we cast it as an ABSTAIN to acknowledge Sun's role in trying to clarify the situation through their FAQ, and most specifically the central role of persistence in the JSR-220 specification and in the Java platform as a whole: "The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.".

This JSR-243/JSR-220 discussion, initiated by some JSR-243 proponents, has only brought disruption on the JSR-220 side and no sign of flexibility on the JSR-243 side. This could give the feeling of a coup to slow down the JSR-220 EG. The J2EE/EJB specification set represents the significant part of today's Java ecosystem. Hence, in order to remain competitive, it is critical to make sure these specifications don't get disrupted.

Due to similarities between JDO and EJB, there should be a fairly straight forward migration path in the future. "At the end of the day, people who use JDO 2 and people who use EJB 3 will have much more in common," said Patrick Linskey, SolarMetric’s CTO and active participant on both specification teams. "Rather than splitting the community in two, vendors like SolarMetric who will provide support for both JDO 2 and EJB 3 will ensure no member of the Java community is disenfranchised."

Although the expectation is that JDO will not be developed beyond minor maintenance releases and a 2.1 draft that clarifies EJB 3 integration, the new JDO draft concludes that "Future revisions of the JDO specification will be done as necessary to reflect the needs of the Java Community".

Yeah Baby !!!

Some sense creeping into the JCP members these days.
Now that JDO 2 has passed, I can sleep properly @ night :-)

Thanks to all those in the community who voiced their support and made the revote successful!

Versant is committed to supporting both JDO 2 and EJB 3 persistence.

Cheers
David - Versant
Versant Open Access

Now bring on the Apache implementation...


PJ Murray
CodeFutures Software

Congratulations to the whole JDO Community! It is good to see that the EC was able to see past the JBoss/Hibernate autroturfing FUD that has been spread to vigosously throughout the past year. Their embittered "abstention" comments show their true colors, and it is good to see people starting to realize this.

JDO 2 is wonderful spec for Object Persistence!

Congratulations to all in the JDO Community for everthing that you have done to create the specification and all you have done to fight for its ratification in the JCP!

I know this sounds geeky, but seeing this news is like my Birthday and Christmas all rolled into one! I'll be celebrating with a couple of beers and one of the fine JDO 2 preview implementations this evening!! :-)

This JSR-243/JSR-220 discussion, initiated by some JSR-243 proponents, has only brought disruption on the JSR-220 side and no sign of flexibility on the JSR-243 side. This could give the feeling of a coup to slow down the JSR-220 EG.

This whole JSR numbering schema can really get confusing at times... which one is 243, and which is 220 again? ;)

Ok, just joking a bit. Lets put it all behind, as now things seem to be much clearer. As I have thought before, releasing JDO 2.0 now and have a version 2.1 dealing with EJB3 migration would be the most reasonable and less disruptive way to fix this mess.

Congratulations to all involved,
Henrique Steckelberg

Although several members of the JDO 2.0 expert group worked tirelessly in order to achieve this outcome specific thanks are due to the wider Java community, without the very volcal support of which we could never have got this far.

My sincere thanks also go to Craig Russell for managing formal discussions within Sun and with the JCP, and to all 16 members of the JCP Executive for their serious consideration of the issues.

JDO targets a wider audience than EJB 3.0 persistence. I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

Well, I though things would get clearer, but now you confused me: isn't EBJ3.0 persistence to become the official Java persistence mechanism, meaning that, after JDO 2.1 sets the migration path to EJB 3.0 persistence, JDO would sort of be "deprecated", and EBJ3 assume its place as the sole persistence standard? Isn't this what was arranged in order to get JDO 2.0 accepted?

Now, by proposing JDO inclusion in J2SE itself, it will only get everyone more trouble, in light of all that has passed, all the recent discussions and this last JDO 2.0 approval effort.

Robin, care to enlighten us on what may we expect of JDO 2.0, 2.1 and future EJB3.0 integration and the expected convergence towards a unified persistence mechanism? Will this be a fight between which spec is better and which will die, or is it already stablished JDO will eventually be deprecated in favor of EBJ3? Or have I got it all wrong?

Thanks,
Henrique Steckelberg

Well, I though things would get clearer, but now you confused me: isn't EBJ3.0 persistence to become the official Java persistence mechanism, meaning that, after JDO 2.1 sets the migration path to EJB 3.0 persistence, JDO would sort of be "deprecated", and EBJ3 assume its place as the sole persistence standard? Isn't this what was arranged in order to get JDO 2.0 accepted?

I see no reason for "tmp" standard, if it is usefull then please maintain and continue to improve it.

Juozas, for me JDO would live forever too, but I am trying to understand its existence in light of all this Unified Persistence Mechanism, and the clash with EJB3 persistence. It seemed clear (at least for me) that JDO would migrate, by means of a 2.1 vesion, towards EJB3 standard. A unified mechanism means one way of doing things, not two, so all I am asking is how will both specs work to become one. It seems (again, to me) that this path is not as clear as I previously supposed, specially after reading Robin's commentaries.

Regards,
Henrique Steckelberg

I see no problems to maintain both specifications, if somebody has motivation. Is it makes sence to approve specification for deprication ?

Sorry - I didn't mean to cloud the picture.

JDO is a JCP standard and evidently it has a wide following in the community. "Mustang" is a bundle of JSRs which will be packaged into J2SE 6.0. The original "Mustang" JSR did not mention JSR-243 so I've asked that it be considered. That's all. And I have asked in my personal capacity - this is not something that the JSR-243 expert group has asked.

Perhaps it is intended that EJB 3.0 Persistence becomes part of J2SE. But there is a precident for technologies making it into the SE platform only after a significant level of maturity has been accomplished, usually after a second major release, so it is unlikely that EJB will provide J2SE with any solution (beyond JDBC) given the April timeframe for the first draft of their spec.

I believe there are users served by JDO who will not be served by EJB 3.0. This does not mean that migration is not an option for the majority in due course. EJB 3.0 is apparently (I'm not on the EG) targetting persistence from a relational perspective and not an object model perspective. It is legitimate, therefore, to presume that not all users will be able to migrate initially.

Either way any addition of JDO to the J2SE platform would have to be approved by the 16-members of the JCP Executive Committee, a group in which my faith has so far been justified.

As for my being "insincere", my personal views on these issues are well known and were thoroughly documented here at the time of the 2004 TSS Symposium: JSR-12 gave JDO the mandate for making objects persistent, and there is no need for a new API to do the same job. Complementing JDO with an OR/Mapping standard (whether in a JDO JSR or another JSR) and providing alternative query capabilities (in a JDO JSR or another JSR) should not alter the API (principal java interface definitions) by which persistence is accomplished. But these are personal views and were evidently lacking in political capital at the time they were aired.

In present times I have striven, in conjunction with many others, for the JDO 2.0 effort to be brought to fruition. I am greatly pleased that the next milestone on this path has been accomplshed. And I look forward to that pint of Guinness (thanks Carl!).

Kind regards, Robin.

And I look forward to that pint of Guinness (thanks Carl!)

Hi Robin,
I loose. Indeed I owe you a beer. I am quite surprised by the result.

Good luck for merging JDO 2.0 with EJB 3.0 ! I am afraid the problems are not over yet.

I have added a short "JDO is not dead" entry to my blog, repeating my arguments from our recent discussion why JDO is not a match for us.

Thanks to you and to Abe for at least listening to my arguments!

And I look forward to that pint of Guinness (thanks Carl!)

Hi Robin,I loose. Indeed I owe you a beer. I am quite surprised by the result.Good luck for merging JDO 2.0 with EJB 3.0 ! I am afraid the problems are not over yet.I have added a short "JDO is not dead" entry to my blog, repeating my arguments from our recent discussion why JDO is not a match for us.Thanks to you and to Abe for at least listening to my arguments!

Carl,
Looks to me that you are after something like Safe Queries as described in this research document by William R. Cook: http://www.cs.utexas.edu/users/wcook/papers/SafeQuery/SafeQueryICSEv2.pdf (his home page is http://www.cs.utexas.edu/users/wcook/).

We accieved something like safe queries in my last project by using code generated persistent Java classes from XML metadata, where our queries could use the Java compiler to check that the queries were according to the Java classes. But that approach is a bit heavy to say the least.

William R. Cook's work seems to adress compile time check on JDO 1.0.1 queries quite beautifully. So if we get the JDO 2.0 into the J2SE package, we might be able to get the Safe Queriy concept right into the Java Language! A nice thought, isn't it! :-)

Shouldn't W R. Cook be in the next JDO expert group?

Cheers,
johan Strandler
A forthcoming rediqiously happy JDO 2.0 user

So if we get the JDO 2.0 into the J2SE package, we might be able to get the Safe Queriy concept right into the Java Language!

Well, not the language (JLS), but it least the JRE. Safe queries are brilliant, and Java sorely lacks them. With Java's future so obviously dedicated to POJO automation, annotations, and classfile enhancement, so safe queries are a natural fit. Shame on EJB-3 for ignoring them, and EJBQL is a joke.

The benefits of safe queries are twofold. First there's the obvious build-time validation. But also safe queries give query language independence, which means that the same safe query can be automatically translated into SQL, XQuery, BPQL, DMQL, or whatever. EJB-3 can't do that. If Sun really wants a universal persistance interface for Java, then safe queries are perfect.

It is trivial to validate "static" queries, but I have no idea how to validate "dynamic" stuff.

It is trivial to validate "static" queries, but I have no idea how to validate "dynamic" stuff.

EJB-3 doesn't support dynamic queries either, so here the bar is quite low. Safe queries could handily surpass EJB-3 by allowing dynamic queries with the possibility of a mapping exception thrown.

It is trivial to validate "static" queries, but I have no idea how to validate "dynamic" stuff.

EJB-3 doesn't support dynamic queries either, so here the bar is quite low. Safe queries could handily surpass EJB-3 by allowing dynamic queries with the possibility of a mapping exception thrown.

Please actually READ THE SPEC before you make such comments. Of course EJB3 supports dynamic queries.

Of course EJB3 supports dynamic queries.

Sure, but we were talking about build-time validation. There's a whole category of errors for dynamic queries that EJB-3 doesn't catch before query execution. That makes EJB-3 queries less economically viable than safe queries. Safe queries can catch more mistakes when building and booting. I know you're not disputing the supremacy of safe queries.

Carl,Looks to me that you are after something like Safe Queries as described in this research document by William R. Cook: http://www.cs.utexas.edu/users/wcook/papers/SafeQuery/SafeQueryICSEv2.pdf

Thank you very much for the pointer, Johan! Indeed, the approach is brilliant, by far better than what we came up with so far. After a quick glance by our team today, there is a good chance that we will build a similar system.

I can see some alternatives to the syntax that William R. Cook uses ...

(1) Single method queries with variable parameter lists, called dynamically by reflection.
(2) Calling conventions by name (filterXXX) on persistent classes.
(3) Passing methods as delegates (on .NET only for now).

...but the principle approach is dead on:
Clean plain code, members and fields described by typesafe [object].[field] notation, use of existing Java syntax, no strings whatsoever, fully refactorable by IDEs.

During development and testing mode the query methods could actually be called directly with the candidate objects, no pre- or post-processing would be necessary.

For maximum runtime speed, method-results and method-fragment-results could be stored, cached and indexed. I see no problems for dynamic query creation.

My first approach for an implementation (I couldn't sleep all night) would be, to create a hierarchical tree from "SafeQuery code", quite similar to the one we already use today. Such a tree - as the basic representation for query process optimisation - is necessary anyway to support other languages like SQL and XPath.

So if we get the JDO 2.0 into the J2SE package, we might be able to get the Safe Queriy concept right into the Java Language! A nice thought, isn't it! :-)

Indeed, that would be a querying revolution and it would have the power to displace SQL! I am looking forward to see comments by the JDO and EJB experts reading along.

Shouldn't W R. Cook be in the next JDO expert group

+1

...and thank you very much again for the link.

Hi Carl,

if we had nice closures and could grab the bytecode for these when passed, it would be entirely possible to parse the bytecode into a query and then re-implement to the DB.

However this would be a fairly advanced approach :-) and the BC can be optimized quite far from easy recognizability. But straightforward field/ stack/ expression stuff could be doable.

In fact I can see a fair amount of use for being able to express Java code directly but having frameworks implement this indirectly against Query or XML or whatever.

In fact any time you're working with an external system this would enable you to express 1st-class Java rather than indirect code. So this would be a fundamentally useful language approach.

But it would probably require comprehensibility standards for BC.


... Cheers,
Thomas
www.powermapjdo.com

Hi Thomas,

if we had nice closures and could grab the bytecode for these when passed, it would be entirely possible to parse the bytecode into a query and then re-implement to the DB.

Yes!
This RFE would help a little bit to be able to specify methods without using strings but closures would indeed be perfect.

Brainstorming with my team, I have come up with the following idea:

public boolean filter(
  Person person,
  int age,
  int cmp){

  if(cmp == Compare.GREATER){
     return person.age < age;
  }

  if(cmp == Compare.SMALLER){
     return person.age < age;
  }
}

// Execution:
<Person>List persons =
  db.query(filter(null, 30, Compare.GREATER));

Compare.GREATER is not part of the API, it's just a simple example for parameter passing to create a dynamic query.

It is part of the calling convention to use the first parameter of the filter method as the class extent.

The execution call looks weird, as if one would be passing the method result (a boolean) to the query() method. However this is the way it could work to specify that you want to pass a closure with parameters. I think a PreCompiler/PostCompiler/ClassLoader could convert this part of the story quite nicely.

[Query execution optimisation]

However this would be a fairly advanced approach :-) and the BC can be optimized quite far from easy recognizability.

True, especially if you would call delegate methods in turn from the querying method. However:
(1) noone stops you from having your "database optimiser" work agaist source code, before compilation.
(2) you can always fall back to instantiating the actual objects to have the real code executed with all the candiate objects. That also makes the "database optimiser" system very nice to debug, you have correct results that you can compare against.

But straightforward field/ stack/ expression stuff could be doable.

My team thinks that we can do this for complex queries also but I agree, it does look like a challenge.

Cheers,
Carl
--
Carl Rosenberger
Chief Software Architect
db4objects Inc.
http://www.db4o.com

This is example from XORM :

public abstract class DeptsWithEmpSalary extends Department {
  public Employee emp; // variable
  public boolean evaluate(float sal) {
    return emps.contains(emp) && emp.getSalary() > sal;
  }
}

It is incomplete implementation and it is possible to optimize it (it is executed in memory at this time), but I do not think it is a good idea, there are many better ways. I prefer to validate SQL queries directly (execute with fake parameters and with "EXPLAIN" prefix, it can print plan for all static queries too).

How about the following:

Object query(Cat cat, String name, double minWeight, double maxWeight){

  return (cat.getName().startsWith(name))
         && weight >= minWeight
         && weight <= maxweight;

}

Execution:

List cats = (List)query(null, "Fritz", minWeight, maxWeight);

Conventions:
- The first parameter is the extent.
- "Object" is used as the return type for query methods to be able to cast to "List".
- Query methods have to return a boolean.
- Query methods also have to be bytecode-enhanced.
- The PersistenceManager has to be taken from the context.

--
Carl Rosenberger
Chief Software Architect
db4objects Inc.
http://www.db4o.com

The first parameter is the extent.

We used the term "extent" quite a bit in the Shlaer/Mellor methodology. It's most relevant today with object prevalance. Why doesn't the EJB-3 persistance specification mention it?

+1...and thank you very much again for the link.

Glad to be to some help. Sorry that you didn't get any sleep though! ;-)

Just a thought: If byte code enhancement is a way to translate Safe Java DDL Queries into target DB-queries, the JDO spec seems easily augmentable to me: The byte code enhancement step is already in place as a development model for JDO.

So the JDO spec might just be extended for Safe Queries wihout much changes of the current spec!

Someone who agrees?

Cheers,
Johan Strandler
Smart Connexion

...but the principle approach is dead on: Clean plain code, members and fields described by typesafe object.field notation, use of existing Java syntax, no strings whatsoever, fully refactorable by IDEs.

We went through the exact same debate about safe queries vs EJB-3 ten months ago here on TSS's front page news.

During development and testing mode the query methods could actually be called directly with the candidate objects, no pre- or post-processing would be necessary. For maximum runtime speed, method-results and method-fragment-results could be stored, cached and indexed.

Ie, object prevalence. There's no need for the optimizations you propose. Even naively implemented object prevalence outperforms networked ODBC.

Thank you for your interest in my work on Safe Queries. In the paper I try to clarify the *problem* that needs to be solved, not just present a new solution. The reason we have so many solutions, I think, is a general lack of agreement (and understanding) about what the problem is. For me, it is simple (I want it all!):
1) good programming model (objects and relationships)
2) appropriate static checks (no code in strings)
3) support for complex and dynamic queries (see the paper for some examples)
4) full transactional support
5) full relational database query optimization
6) scalability (no in-memory/cached single-process models)

People tend to focus either on the top or bottom of the list, but not both, so the solutions are only partial. There *is* a fundamental conflict between strong OO modularity and full query optimization; unless this problem is addressed head-on, the solution will always be unsatisfying.

I was hoping that the JDO community would pick up on the idea. We based our prototype on JDO because it provided a good foundation. But the technique can be used in other interfaces too. We used a Java preprocessor in the prototype, but I now think that byte-code manipulation would be better. This also fits with the JDO approach.

I am happy to discuss Safe Queries in more detail or answer any questions. Don't let my academic title fool you: I have many years of experience building commercial enterprise applications.

William Cook
Assistant Professor, UT Austin Computer Sciences
http://www.cs.utexas.edu/~wcook

A unified mechanism means one way of doing things, not two, so all I am asking is how will both specs work to become one.

Maybe if I worked for a J2EE vendor, I might be less concerned that unification won't support J2SE.

Robin Roos:
I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

Henrique Steckelberg:
isn't EBJ3.0 persistence to become the official Java persistence mechanism, meaning that, after JDO 2.1 sets the migration path to EJB 3.0 persistence, JDO would sort of be "deprecated", and EBJ3 assume its place as the sole persistence standard?

Henrique, Robin, all,

I'm very glad Robin brought this topic up, and glad that Henrique has raised issue with it - the particulars of the relationship between JDO and EJB must be addressed sooner or later, and better that we don't just sweep it under the carpet, espousing platitudes about future oneness with EJB without any critical thinking on the matter. Let's look at the implications of, and what we mean when we talk about a 'migration path' from JDO to EJB 3:

Having EJB 3 serve as the 'sole persistence standard' for Java has an inherent problem: its name. Enterprise
Java Beans is appropriately targeted toward the enterprise Java community, whereas JDO (Java Data Objects) is absolutely general, for use anywhere within Java. The purpose of, and context for EJB is much more specific than JDO. I cannot imagine using EJB, in any variation of it's current form in my next Swing application, for example; or for that matter anything I would run outside of a container managed environment. This specificity toward enterprise Java is reinforced by the EJB JSR itself; the following is directly from JSR 220 (EJB 3.0 Java Specification Request):

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

JavaTM 2 Platform, Enterprise Edition (J2EE) 1.5.

For EJB persistence to become useful throughout Java, and act as a sole persistence standard, it would have to be retargeted for inclusion into J2SE. This seems unlikely, given that it's name is Enterprise Java Beans.

Now, that having been said, it stands to reason that the persistence core used in EJB 3.0 might be extracted out, and could emerge as the sole persistence standard. This would make for sensible layering, usability throughout Java, and would be a fine candidate for inclusion in J2SE 6.0. There is one small problem: by and large, the community has not seen or used the EJB 3 persistence mechanism directly, so it's hard to have a meaningful conversation about it.

So then, let's talk about it: What exactly is the persistence mechanism within EJB 3.0? Is it extractable as a standalone API? Ultimately, if we want to talk about migration, let's have a look under the hood of EJB and ask the quest
ion: Why not have JDO itself be the persistence mechanism that underlies EJB? EJB could be said to be a large superset of what's available in JDO. I submit that one way to 'migrate' from JDO to EJB is to have EJB use JDO directly.

I would love to hear from the EJB and JDO expert group members as to the technical considerations of a move like this. Let's set aside the political issues for a moment, and ask the question again newly: What are the technical considerations of having the best of both worlds? EJB and JDO, where EJB uses JDO? In this sort of a scenario, it would be natural to include JDO in J2SE 6.0.

Thanks, all.

- Chris

Chris Beams
Software Engineer
http://chrisbeams.com/blog

Great News !!!

Our company is using JDO2.0 features , but as vendor extensions. I can't wait to see the official JDO 2.0 implementation.

Big thanks to the community and everyone who fought so
hard to make sure JDO survived.

Regards
Alessio Harri

JDO targets a wider audience than EJB 3.0 persistence. I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

This makes no sense. Why would you try to put the API's in J2SE after you agreed to support the migration to JSR 220? It gives the appearance that you were making insincere commitments for the sole purpose of getting your JSR passed.

The community deserves a pat on the back for speaking up. Only the community can speak for itself, not politicians who want to tell us "what is best" for us.

JDO rules!

-geoff

Let's remember that Sun is just ONE member of an Executive Committee, and JSR comprised of a number of companies and individuals. The whole intent is to support the COMMUNITY, no thte objectives of individual companies, and we have in fact seen that happen!

The "open letter" spoke for the opinion of one company, Sun. What we have seen here is that the opinions of many other companies and individuals support the charter of JDO's JSR, which is POJO persistence, regardless of if you are in a container or not.

I see this success for JDO as a big endorsement of the JCP process, and proof that regardless of what extra-procedural maneuvering takes place, the itegrity of the JSR process remains intact. I really think the community has spoken and it is clear that JDO is an API that the community will use and improve for years to come. JDO is the standard for POJO persistence.

-geoff

I see this success for JDO as...

I'm not sure I'd call planned deprication a "success".

The existing JDO community will be supported, and we should expect to see a 2.1 release in the near term that outlines migration to EJB 3. Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java

I see this success for JDO as...

I'm not sure I'd call planned deprication a "success".
Well, if you're so willing to accept Sun's word as gospel, I guess we need to go ahead and let the Hibernate and Ibatis teams know that they should go ahead and wrap up their current version and start preparing for deprecation as well.

Umm... no. Since when has Sun's desire to have EJB be the ONLY persistence spec (even if you only count J2EE) actually meant that this was actually the case. The market and developers like ourselves will decide what the best persistence mechanism for our particular circumstances.

Since when has Sun's desire to have EJB be the ONLY persistence spec (even if you only count J2EE) actually meant that this was actually the case. The market and developers like ourselves will decide what the best persistence mechanism for our particular circumstances.

I agree entirely. Does there have to be one solution/tool/spec to address database persistence (or indeed any problem)? I understand the need to standardize, however, we are not all robots. Now that the JDO 2 spec is approved, I hope the EJB 3 spec will help simplify J2EE so that developers can concentrate on solving real business problems.

~ Greg

TopMind Systems

Well, if you're so willing to accept Sun's word as gospel, I guess we need to go ahead

It is not the word of Sun only, but of all the other voters as well. As I understand it, they want an unambigous statement with regard to a Java persistence mechanism, and they have chosen to pursue that under the umbrella of JSR 220.

let the Hibernate and Ibatis teams know that they should go ahead and wrap up their current version and start preparing for deprecation as well

both of these are tools with "prorietary" APIs, so there is nothing to be deprecated. I think the wisest thing the JDO folks can do at this time is keep a low profile (WRT propaganda, not technology), and let the market decide further. The political game seems settled to me.

christian

Well, if you're so willing to accept Sun's word as gospel, I guess we need to go ahead

It is not the word of Sun only, but of all the other voters as well. As I understand it, they want an unambigous statement with regard to a Java persistence mechanism, and they have chosen to pursue that under the umbrella of JSR 220.

This is not the situation. Just look at Apache's comments.
BEA even suggests the possibility (very likely in my view) that an overarching persistence strategy may not be achieved.

I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

Wow, this is the most irresponsible statements I've seen in a long time, and that's saying a lot. Here we are, at a cross road of opportunity for everyone, and you go an say something tantemount to a declaration of war.

Just to be clear amongst the all the eg and astroturf backslapping, Sun reiterated that JSR 220 is the intended standard Java persistence API moving forward. This is not some breath of new life, it's the formal beginning of the end.

 - Don

Hi Don

Sun reiterated that JSR 220 is the intended standard Java persistence API moving forward.

And Sun has a veto over all changes to all platform editions (J2ME, J2SE and J2EE). Therefore Sun's hand effectively cannot be forced in this issue.

I'm subscribing to the principle of "if you don't ask you won't get". Am I wrong to ask?

Kind regards, Robin.

One company cannot dictate what the community wants. Any attempt to do so going forward would be patently ridiculous. What *is* irresponsible is jeopardizing the "C" in JCP by taking the presumptuous attitude that one company, or a cabal of companies can impose its will on a community that has very vocally mandated JDO.

We have to get over the notion that the Java community is a bunch of dumb sheep and only the big companies know what is best. Apache said it best, "let a thousand flowers bloom". Meritocracy has a place in Java standards, and developers want choice. The community hsa spoken on this. Period.

-geoff

I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

Robin, fantastic! I think many out there just don't get that JDO has a heritage that goes all the way back to JDO 1.0, JSR 12, obviously one of the first JSRs. JDO has always had the charter for J2SE POJO persistence. Making JDO part of the J2SE standard libraries is a most natural fit. Some day all this FUD will blow away and developers will use jdo as commonly as jdbc. For now, we still have to go through the standard arguments against change. The technical merits of JDO are beyond debate by all except those with the most entrenched interests..

Some day all this FUD will blow away and developers

FUD?

Just to be clear amongst the all the eg and astroturf backslapping, Sun reiterated that JSR 220 is the intended standard Java persistence API moving forward. This is not some breath of new life for JDO, it's the formal beginning of the end.

 - Don

Sun reiterated that JSR 220 is the intended standard Java persistence API moving forward. This is not some breath of new life for JDO, it's the formal beginning of the end.&nbsp;- Don

So it is entirely consistent with Sun's vision to use JDO 2.0 as a stepping stone towards EJB 3.0 persistence.

Sun reiterated that JSR 220 is the intended standard Java persistence API moving forward. This is not some breath of new life for JDO, it's the formal beginning of the end.&nbsp;- Don

"Tis many a slip 'twixt the cup and the lip"

First EJB 3 has to become a published approved standard (sometime in 06 I'm guessing). Then it has to prove itself (if it's going to happen, should be done by '07). Then it can enjoy its nod to be the sole standard thereafter. So we've got a ways to go before EJB 3 POJO persistence vanquishes JDO.

I'm happy with the expectation that the best persistence layer will win! I'm hoping that everyone else will be happy with the same outcome.


David

blah blah blah, fud, fud, fud

Sorry, wrong. There are multiple implementations of EJB 3 today. Container and containerless support, clear migration paths, etc.

http://www.oracle.com/technology/tech/java/ejb30.html

 - Don

Sorry, wrong. There are multiple implementations of EJB 3 today. Container and containerless support, clear migration paths, etc.http://www.oracle.com/technology/tech/java/ejb30.html&nbsp;- Don

Yes, there are experimental implementations of a draft which can be totally different from the final spec, a spec which will not be out for a long while, as far as I can see.

Sorry, wrong. There are multiple implementations of EJB 3 today. Container and containerless support, clear migration paths, etc.http://www.oracle.com/technology/tech/java/ejb30.html&amp;nbsp;- Don

Yes, there are experimental implementations of a draft which can be totally different from the final spec, a spec which will not be out for a long while, as far as I can see.

Please note this EJB 3.0 plans to go proposed final draft by JavaOne (June 2005) so there will not be many changes in the specification. And this is not experimental implementation and we are planning to include EJB3 features in a production release planned this summer.

regards
Debu Panda
Oracle

I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

Robin, fantastic! I think many out there just don't get that JDO has a heritage that goes all the way back to JDO 1.0, JSR 12, obviously one of the first JSRs. JDO has always had the charter for J2SE POJO persistence. Making JDO part of the J2SE standard libraries is a most natural fit. Some day all this FUD will blow away and developers will use jdo as commonly as jdbc. For now, we still have to go through the standard arguments against change. The technical merits of JDO are beyond debate by all except those with the most entrenched interests..

You do realize that by endorsing Robin's move, you are the one perpetuating the FUD and the confusion in the community, right?

--
Cedric

You do realize that by endorsing Robin's move, you are the one perpetuating the FUD and the confusion in the community, right?-- Cedric

The real confusion was brought about by Sun's Open Letter and the inferences people made from it. An "Open Letter" stated Sun's position. It was great to get clarification from Sun, on what Sun wanted. Sun was trying to be a good shepherd. But the fact of the matter is that JSR 243 is a COMMUNITY standard representing the interests of many other companies and individuals, besides those who take a view that the Java Community deserves only a single solution for persistence.

I believe developers deserve a choice. I believe it is perfectly OK to have more than one solution, and I sure as hell don't believe in silver bullets. JDO isn't a silver bullet and EJB sure isn't either. Take away developer's choices and we are all going to get burned. Let's let the COMMUNITY decide what it wants in Java.

-geoff

I have written to the JSR-270 expert group proposing that JDO 2.0 be considered for inclusion in "Mustang" (J2SE 6.0). This would make the javax.jdo package part of the JDK/JRE.

You *have* to be kidding, right?

--
Cedric

You *have* to be kidding, right?

Nope. It's something I've been meaning to do for a while and, with JDO 2.0 close to completion and prompted by the "Mustang" thread on TSS (Feb 18th) I finally got around to doing so mid last week. But it was probably inopportune to mention *today* that I had done. Apologies for the distraction.

Kind regards, Robin.

Just as a reminder, this is from the original post:

The existing JDO community will be supported, and we should expect to see a 2.1 release in the near term that outlines migration to EJB 3. Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java

I think this leaves little room for doubt about the intention of the settlement, no matter in what camp ones sympathies lie.

christian

Just as a reminder, this is from the original post:

The existing JDO community will be supported, and we should expect to see a 2.1 release in the near term that outlines migration to EJB 3. Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java

I think this leaves little room for doubt about the intention of the settlement, no matter in what camp ones sympathies lie. christian

EJB was initially a distributed component model. Is this no longer the case? The reason I ask this question is because it doesn't really make sense to house a POJO persistence standard there. However, I think it makes perfect sense to *use* such a standard for the persistence part of EJB. We've been through this discussion before with JDO a while back.

The Java community is making the proper selection and use of Java technologies very confusing here. Thanks a lot! I hope the big Java brains pull this thing out at some point and put it where it belongs. I'm assuming this poor choice (and complete lack of common sense) is due to politics and convenience.

EJB was initially a distributed component model. Is this no longer the case?

JSR-220 (EJB 3.0) is producing two specifications, one of which will be for a new POJO persistence and OR/Mapping capability, intended to be usable from inside and outside an EJB container. EJB 3.0 will be part of J2EE 5.0.

Kind regards, Robin.

EJB was initially a distributed component model. Is this no longer the case? The reason I ask this question is because it doesn't really make sense to house a POJO persistence standard there. However, I think it makes perfect sense to *use* such a standard for the persistence part of EJB. We've been through this discussion before with JDO a while back.

It seems clear to me from the announcements, that JSR 220 will bring forth a POJO persistence API that can be used under J2SE as well (please, no "we already have one" now). The choice of the JSR umbrella may be confusing, I agree.

chris

EJB was initially a distributed component model. Is this no longer the case? The reason I ask this question is because it doesn't really make sense to house a POJO persistence standard there. However, I think it makes perfect sense to *use* such a standard for the persistence part of EJB. We've been through this discussion before with JDO a while back.

It seems clear to me from the announcements, that JSR 220 will bring forth a POJO persistence API that can be used under J2SE as well (please, no "we already have one" now). The choice of the JSR umbrella may be confusing, I agree.chris

That is correct, but the umbrella for this spec and the way people have been referring to it on this and other threads (specifically, as EJB 3 POJO persistence blah blah...) causes a lot of unnecessary confusion.

JSR 220 will bring forth a POJO persistence API that can be used under J2SE as well (please, no "we already have one" now). The choice of the JSR umbrella may be confusing, I agree.chris

That is correct, but the umbrella for this spec and the way people have been referring to it on this and other threads (specifically, as EJB 3 POJO persistence blah blah...) causes a lot of unnecessary confusion.

Given the intended migration path from JDO 2.0 to the new POJO persistence API, which is intended for used with J2SE as well as EJB 3.0 within J2EE, it would have made more sense to specify the new POJO persistence API under a new JSR for JDO 3.0.

Given the intended migration path from JDO 2.0 to the new POJO persistence API, which is intended for used with J2SE as well as EJB 3.0 within J2EE, it would have made more sense to specify the new POJO persistence API under a new JSR for JDO 3.0.

It all boils down to what I consider a not very good idea that there should be one solution, a silver bullet. When we adopt the mindset that there is one solution, all the technology communities have to fight and have turf wars over who "owns" the spec. And the outcome is just a big loss for developers. Believe or not there is a huge diversity of opinion over how persistence should be done, even at the level of modeling entities vs. POJO's, without even getting into whether or not a "container" should be in the middle. Rather than trying to pick a "winner" for the spec, we should simply have different specs with as high a degree of pluggability as possible between them.

Why do we talk about "intended migration" as if the java community is a bunch of sheep who need to be herded to a particular solution? If JDO is suiting your needs, why would you migrate? If EJB is meeting you needs why switch? In fact, after three or four years of reading best practices and whitepapers, and books telling us to build simple web apps with completely missapplied "enterprise/entity" technology, I think there is skepticism in the community about being crammed into any particular java technology/stack or being told to switch to the new thing that is going to solve your problems.

-geoff

It seems clear to me from the announcements, that JSR 220 will bring forth a POJO persistence API that can be used under J2SE as well (please, no "we already have one" now).

What I am interested in some definitive statements as to what technical benefits the JSR 220 POJO persistence API is likely to provide over JDO 2.0. My impression (and I am prepared to be corrected) is that it has more restrictions on what can be persisted and how things can be persisted than JDO 2.0. In the end, no amount of stating that the new API is intended to be the future standard will move current JDO users to the new API unless it is superior to JDO. If it is, I'll gladly migrate. If is is simply different, but not better, then I suspect it will be like the Swing/SWT situation - both will be used, and what is defined as the 'intended standard' will be irrelevant.

(please, no "we already have one" now)

Sorry, but we do! This simple fact has been doing my head in since I heard about the new API. Still, perhaps a list of technical benefits of the new API will stop me being so puzzled about the technical need for it!

The Java community is making the proper selection and use of Java technologies very confusing here. Thanks a lot! I hope the big Java brains pull this thing out at some point and put it where it belongs. I'm assuming this poor choice (and complete lack of common sense) is due to politics and convenience.

The "Entity Bean3 -- EJB3 POJO EJB" saga is arguably the most bizarre in the history of JCP3.

hooray for JDO! My faith in the JCP has been restored - technical merit overcame politics and conflicts of interest.

Put me down as +1 for including JDO as part of J2SE 6, and +1 for 'why not just include JDO as the new POJO persistence mechanism in EJB 3?' Now *that* would be a nice easy migration path for JDO users such as myself.

Either way , with JDO 2 alive and well, we can let the market decide.

Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java.

When I initially heard about the unified POJO persistence mechanism, I thought it was supposed to be in a separate spec under the EJB3 banner temporarily. Is that no longer the case? I was also under the impression that this spec would only deal with ORM - with the emphasis on R. Otherwise, can we really sunset JDO? Comments please.

Thank you to the EC, for recognizing the value JDO 2.0 can deliver to the JDO community today. Thank you to BOTH spec leads who, consistent with their joint letter, worked with the committee to convince them of the value of JDO 2.0 as a bridge solution. Thank you to the Java community for speaking your voice on this.

I don't have ANY horse in this race. I don't work for a vendor, and don't use JDO, but persistence is an issue I address regularly (mostly using Hibernate), and real, usable standards for POJO persistence are something I believe strongly in. So thank you all.

Finally!!!

Now the Java community can use JDO2 implementations overcoming JDO1 limitations.

Enjoy! ;-)

bye,
Luca Garulli
OrienTechnologies.com - Light ODBMS, All in one JDO solution
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)

What does this mean to Hibernate? Weren't there guys who developed hibernate doing the JSR220?

Hibernate lives, didn't you read the threads yesterday (nicely timed, eh?).

I imagine the JBoss/Hibernate guys are having to refactor their profit projections, now that their product will not have the defacto monopoly on persistence for Java for the next year.

Congrats to the JSR 243 guys, and let's hope the EJB3 POJO Persistence will adopt the features in JDO2 so it will be useful.

I imagine the JBoss/Hibernate guys are having to refactor their profit projections, now that their product will not have the defacto monopoly on persistence for Java for the next year.

Hibernate is doing fine, and is already largely feature-compatible (just not API compatible) with JDO.

Look, the JDO JSR is about JDO and JDO customers, not about dissing Hibernate or EJB.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

I imagine the JBoss/Hibernate guys are having to refactor their profit projections, now that their product will not have the defacto monopoly on persistence for Java for the next year.

LOL! :-)

Congrats to the JSR 243 guys, and let's hope the EJB3 POJO Persistence will adopt the features in JDO2 so it will be useful.

The sound of two hands clapping! :-)

I want a ballot recount!

BEA voted Yes concluding that:

After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved.

Seems BEA is leaving the option open to pull out of the Entity Bean bandwagon.

BEA voted Yes concluding that:

After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved.

Seems BEA is leaving the option open to pull out of the Entity Bean bandwagon.

It was meant "Entity Bean 3.0 bandwagon"

Now that ejb has become jdo, we don't need jdo any more...

I think that the lesson to be learned is that there must be only one component model, the primitive model of java classes and objects, not a model for transactions, another for management, etc...

Now that ejb has become jdo, we don't need jdo any more.

Can EJB-3 be Web Start deployed? If it can't, then it can't be universal. And that would be our loss.

It's good to see JDO 2 accepted. We have a number of customers using it (JDO 1.0.1 plus the "expected to become a standard" JDO 2.0 extensions from various JDO vendors and open source projects) and it would have been very upsetting to them if the spec weren't made official.

I'm curious to see how close the final EJB 3 persistence is to the model supported by JDO. I understand the APIs won't be identical, but would it be easy to switch from one to the other? Some of the concepts and APIs in the early EJB 3 specs do appear to have direct (1:1) corrolaries in the JDO API.

I'm curious for a couple reasons. For example, could an EJB container use JDO as its persistence implementation? Or vice versa? That is, will it be efficient and simple for one to wrap the other? Also, will the same application objects be persistable with either JDO or EJB without any changes?

For reference, see:

http://jcp.org/aboutJava/communityprocess/pr/jsr243/index2.html
http://java.sun.com/products/ejb/docs.html

p.s. too funny .. while trying to post this, I got a JDO exception about a database timeout

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

p.s. too funny .. while trying to post this, I got a JDO exception about a database timeoutPeace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters

Now that is funny! LOL!

p.s. too funny .. while trying to post this, I got a JDO exception about a database timeout

How ironic!

Yes, there is a lot of similarity between EJB and JDO, although there are differences also.

In principle, replacing invocations of PersistenceManager.makePersistent() with EntityManager.persist() would get you a fair distance in your migration.

I see no reason why an implementation of EJB 3.0 persistence could not be written on top of a JDO implementation instead of engineering a new persistence engine. JDO vendors, however, who already own persistence engines, are more likely to implement on top of their existing persistence engines instead of implementing on top of their JDO abstraction layer.

The object models you persist through EJB 3.0 could easily be persisted through JDO. But the reverse is not necessarily true. JDO can handle interesting object model configurations (combinations of private fields, abstract or final classes, lack or property accessor/mutator methods, etc.) which are not directly supported by EJB 3.0 at this time as far as I know.

I think EJB 3.0 implementations are likely to compromize the instanceof operator, whereas JDO respects it, so some specific client code may need to change but to many this is less important.

Others will no doubt contribute other notable similarities and differences.

Kind regards, Robin.

Hi Robin,

Nice post. While obviously there is difference between the APIs, I agree that underlying instance management/ storage engines can likely be very similar.

In principle, replacing invocations of PersistenceManager.makePersistent() with EntityManager.persist() would get you a fair distance in your migration.

What a concise summation. I'm definitely in favour of shorter APIs, my only question is why Sun comes up with such long and meaningless names in the first place !

InstanceMgr, EntityMgr, PersistMgr all have the benefit of being short and sweet. :-) Maybe this suggests an extra 3 JSRs need be started... one for each... before we can resolve which one is really the standard.

Oh yeah, the standard was EJB 1 - pity it didn't handle objects or relationships in an OO language...

JDO can handle interesting object model configurations (combinations of private fields, abstract or final classes, lack or property accessor/mutator methods, etc.)

I feel this is kind of important. Properties are for the model, storage is meant to be orthogonal. Model behaviours and side-efefcts should be separate from storage.

Like plugging a fridge in; the power cord goes out the back, not out the front.

I think EJB 3.0 implementations are likely to compromize the instanceof operator, whereas JDO respects it

Gack, why is this? Aside, my guess is that HB compromises the == operator with proxies, but I'm not really down with any of this.

Just imagine how much time one could waste with faulty == or instanceof operators, and exactly how much fun it would be debugging that c*#@, hour in and out...

Sounds like Class Loaders !


Cheers,
Thomas
www.powermapjdo.com

In principle, replacing invocations of PersistenceManager.makePersistent() with EntityManager.persist() would get you a fair distance in your migration.What a concise summation. I'm definitely in favour of shorter APIs, my only question is why Sun comes up with such long and meaningless names in the first place !InstanceMgr, EntityMgr, PersistMgr all have the benefit of being short and sweet. :-)

Please don't start this debate. PersistenceManager and/or EntityManager are infinitely better as a names then PersitMgr, EntityMgr, etc. (the shorter names remind me of old hard to read, hard to maintain C code. Ohhh just got a shiver).

I'll take the extra few key strokes for code readability EVERY TIME!!!

In principle, replacing invocations of PersistenceManager.makePersistent() with EntityManager.persist() would get you a fair distance in your migration.What a concise summation. I'm definitely in favour of shorter APIs, my only question is why Sun comes up with such long and meaningless names in the first place !InstanceMgr, EntityMgr, PersistMgr all have the benefit of being short and sweet. :-)

Please don't start this debate. PersistenceManager and/or EntityManager are infinitely better as a names then PersitMgr, EntityMgr, etc. (the shorter names remind me of old hard to read, hard to maintain C code. Ohhh just got a shiver).I'll take the extra few key strokes for code readability EVERY TIME!!!

That's why I always put an explicit "this is a sarcastic post" advice after some ironic posts. Some people can't tell it just by reading. :)

InstanceMgr, EntityMgr, PersistMgr all have the benefit of being short and sweet. :-) Maybe this suggests an extra 3 JSRs need be started... one for each... before we can resolve which one is really the standard.

I think it is a good idea. Probably it is a good idea to invent a new query language per stantard too, it can help to resolve which one is the most object oriented.

I think it is a good idea. Probably it is a good idea to invent a new query language per stantard too, it can help to resolve which one is the most object oriented.

You must not reinvent it !
There exist one extrem powerfull Object Query Language it is called OQL.
But if you say this Word too loud some People will be realy pissed off ;-)
troll feeding time

Hi Cameron

I understand the APIs won't be identical, but would it be easy to switch from one to the other? Some of the concepts and APIs in the early EJB 3 specs do appear to have direct (1:1) corrolaries in the JDO API.I'm curious for a couple reasons. For example, could an EJB container use JDO as its persistence implementation? Or vice versa? That is, will it be efficient and simple for one to wrap the other? Also, will the same application objects be persistable with either JDO or EJB without any changes?

That is certainly where we are headed with Versant Open Access. Our customers will be able to use the same model with the JDO and/or EJB3 persistence API in the same application. JDO 2 supports a wider range of domain models and field types than EJB 3 so we will provide these features as extensions to EJB 3 applications.

Cheers
David

Hi Cameron

I understand the APIs won't be identical, but would it be easy to switch from one to the other? Some of the concepts and APIs in the early EJB 3 specs do appear to have direct (1:1) corrolaries in the JDO API.I'm curious for a couple reasons. For example, could an EJB container use JDO as its persistence implementation? Or vice versa? That is, will it be efficient and simple for one to wrap the other? Also, will the same application objects be persistable with either JDO or EJB without any changes?

That is certainly where we are headed with Versant Open Access. Our customers will be able to use the same model with the JDO and/or EJB3 persistence API in the same application. JDO 2 supports a wider range of domain models and field types than EJB 3 so we will provide these features as extensions to EJB 3 applications.CheersDavid

Does anyone know if the EG is planning to expand the EJB3 Persistence API scope to cover the entire range of domain models that are persistable under JDO2?

It would seem to be a shame and a bit awkward to have to take a step back a year or so from now from using a fully standardized API (JDO2) to a standard+vendor extensions API (EJB3) for the same domain object model.

SUN implements entity EJB 2.1 by JDO already.