Solarmetric has released version 3.3.0 of Kodo, their JDO implementation. There are a lot of improvements, including JDO 2 preview support.

A short list of updates:

• Many new JDO 2 preview features, including Single Field Identity, which allows for the use of application identity without writing object id classes when using a single primary key field
  
• Many improvements to the Kodo Workbench
• Finer grained control over timed cache invalidation
• Support for Apache Derby
• Support for JMX 1.2
• Performance enhancements to Remote PersistenceManager capability
• Improved support for Java 5 enums and generics
• Many other new features and bugfixes

Links:

• Release Notes
• Evaluate

JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification, but JDO vendors are gearing up to support EJB persistence themselves, since EJB 3 is an ORM model itself now. Thus, EJB 3 might breathe new life (more life) into the JDO market than it had, rather than killing off JDO as might have been expected.

What do you think?

Congrats. Is JDO2.0 "final final" now? If so, when will KODO be certified?

Peace,

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

JDO 2.0 (JSR 243) is a standard people can use today. The combining of the expert groups for JSR 243/220 mean they now breathe as one. These two technologies are already so closely aligned one can see the mist. Open standards is really the only way to go for long living technologies.

See the cover story in JavaPro on this very issue.

http://javapro.texterity.com/javapro/200503/

Robert Greene
Versant Corporation

JDO 2.0 (JSR 243) is a standard people can use today. The combining of the expert groups for JSR 243/220 mean they now breathe as one. These two technologies are already so closely aligned one can see the mist. Open standards is really the only way to go for long living technologies.See the cover story in JavaPro on this very issue.http://javapro.texterity.com/javapro/200503/Robert GreeneVersant Corporation

Just scanned the article and it looks great Robert. It looks like it will clear up a lot of misconceptions. I will be joyfully taking an indepth read over lunch.

Great news from Solarmetric.

The Lifecycle Events are a welcome feature that we (JInspired) will be taking immediate advantage of in providing a simplified but powerful JXInsight/JDBInsight integration with the Kodo runtime.

Our integration will associate additional execution contextual information such a XA/Non-XA transactions, distributed trace stack, local/remote component Java callstack, codesoures and deployment modules, as well as profile (JVMPI) events with the various life cycle events and intervals between pre and post event notifications.


Regards,

William Louth
JXInsight Product Architect
CTO, JInspired

"J2EE tuning, testing and tracing with JXInsight"
http://www.jinspired.com

JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification

I realise I am being pedantic, but:

I was not aware that JSR specifications had limited lifespans. JSR 220 states that it does not render any existing specifications obsolete, deprecated, or in need of revision.

Perhaps JDO's effective lifespan as a relational persistence specification may be limited by EJB 3.0, but that will surely, in the end, be a matter of developer choice.

but JDO vendors are gearing up to support EJB persistence themselves, since EJB 3 is an ORM model itself now. Thus, EJB 3 might breathe new life (more life) into the JDO market than it had, rather than killing off JDO as might have been expected.What do you think?

As there will be many products that allow a developer to choose EJB 3 (optimised for relational stores) or JDO (store agnostic), and even use them both at the same time in the same application, developers will be able to select which API is more appropriate, I agree. Let developers use EJB 3 for what it designed for, and let them use JDO for that that is designed for. Java has always been about flexibility and choice, not restricting options. Choice is good.

I realise I am being pedantic

Forgive my bad manners. In addition to my usual ranting, I should have added my congratulations.

Congratulations SolarMetric on the most recent release of your fine JDO implementation. I have used Kodo successfully on a couple of projects now and look forward to checking out the new release.

By the way, Do any of you at SolarMetric have any ideas on when the JDO2 spec will become final?

Great work! It's a race to see how many vendors can achieve JDO 2.0 support by Java One. I bet most will have it, and you guys are leading the pack.

-geoff

JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification

Disclosure: I work for Xcalia, currently a JDO vendor, and in the future also an EJB 3.0 persistence vendor, and a member of both JSRs 220 & 243.

Joseph, this really confuses people.

JDO's lifespan is indefinite. There is no reason to think that JDO will ever go away, especially now that version 2.0 has been approved by the EC in its latest vote. Further, it has been clearly demonstrated that there has been a substantial market for JDO technology for quite some time, and the similarities between JDO 2.0 and EJB 3.0 persistence are a testament to the fact that JDO did a good job of defining what Java object persistence should look like.

If a user adopts JDO today, they will be able to use it indefinitely. If they wish to port to EJB 3.0 persistence, they would have no technical reason to do so, but they certainly could. I can't predict the future, but I expect there to be a JDO 2.1 that addresses the JDK 5.0 features that weren't present at the time the JDO 2.0 effort was begun back in August, 2003 (see here & here).

Fowler's "Anemic Domain Model" antipattern, which is far too prevalent in our industry. Better, you can start today with JDO 2.0, and switch later if you want to, most likely without even changing persistence vendors, as it will be almost trivial for any JDO vendor to implement EJB 3.0 persistence.

Sincerely,
Matthew

For some reason, when I posted my response, part of my message was dropped. Here's the repost; I hope it doesn't bomb again.

JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification

Disclosure: I work for Xcalia, currently a JDO vendor, and in the future also an EJB 3.0 persistence vendor, and a member of both JSRs 220 & 243.

Joseph, this really confuses people.

JDO's lifespan is indefinite. There is no reason to think that JDO will ever go away, especially now that version 2.0 has been approved by the EC in its latest vote. Further, it has been clearly demonstrated that there has been a substantial market for JDO technology for quite some time, and the similarities between JDO 2.0 and EJB 3.0 persistence are a testament to the fact that JDO did a good job of defining what Java object persistence should look like.

If a user adopts JDO today, they will be able to use it indefinitely. If they wish to port to EJB 3.0 persistence, they would have no technical reason to do so, but they certainly could. I can't predict the future, but I expect there to be a JDO 2.1 that addresses the JDK 5.0 features that weren't present at the time the JDO 2.0 effort was begun back in August, 2003 (see here & here).

The Fowler's "Anemic Domain Model" antipattern, which is far too prevalent in our industry. Better, you can start today with JDO 2.0, and switch later if you want to, most likely without even changing persistence vendors, as it will be almost trivial for any JDO vendor to implement EJB 3.0 persistence.

Sincerely,
Matthew

Sorry, folks, my bad. I missed a closing quotation mark. Here's my correction. I sure wish TSS had a "preview post" feature!

JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification

Disclosure: I work for Xcalia, currently a JDO vendor, and in the future also an EJB 3.0 persistence vendor, and a member of both JSRs 220 & 243.

Joseph, this really confuses people.

JDO's lifespan is indefinite. There is no reason to think that JDO will ever go away, especially now that version 2.0 has been approved by the EC in its latest vote. Further, it has been clearly demonstrated that there has been a substantial market for JDO technology for quite some time, and the similarities between JDO 2.0 and EJB 3.0 persistence are a testament to the fact that JDO did a good job of defining what Java object persistence should look like.

If a user adopts JDO today, they will be able to use it indefinitely. If they wish to port to EJB 3.0 persistence, they would have no technical reason to do so, but they certainly could. I can't predict the future, but I expect there to be a JDO 2.1 that addresses the JDK 5.0 features that weren't present at the time the JDO 2.0 effort was begun back in August, 2003 (see here & here).

The article cited in this thread by Robert Greene should give you a good idea of the overlap between the two specifications.

The good news is that old-school entity beans are gone, and transparent object persistence is now considered mainstream. We can now focus on becoming better object modelers and avoiding Fowler's "Anemic Domain Model" antipattern, which is far too prevalent in our industry. Better, you can start today with JDO 2.0, and switch later if you want to, most likely without even changing persistence vendors, as it will be almost trivial for any JDO vendor to implement EJB 3.0 persistence.

Sincerely,
Matthew

Sorry, folks, my bad. I missed a closing quotation mark. Here's my correction. I sure wish TSS had a "preview post" feature!

JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification

Disclosure: I work for Xcalia, currently a JDO vendor, and in the future also an EJB 3.0 persistence vendor, and a member of both JSRs 220 & 243.Joseph, this really confuses people.JDO's lifespan is indefinite. There is no reason to think that JDO will ever go away, especially now that version 2.0 has been approved by the EC in its latest vote. Further, it has been clearly demonstrated that there has been a substantial market for JDO technology for quite some time, and the similarities between JDO 2.0 and EJB 3.0 persistence are a testament to the fact that JDO did a good job of defining what Java object persistence should look like.If a user adopts JDO today, they will be able to use it indefinitely. If they wish to port to EJB 3.0 persistence, they would have no technical reason to do so, but they certainly could. I can't predict the future, but I expect there to be a JDO 2.1 that addresses the JDK 5.0 features that weren't present at the time the JDO 2.0 effort was begun back in August, 2003 (see here & here).The article cited in this thread by Robert Greene should give you a good idea of the overlap between the two specifications.The good news is that old-school entity beans are gone, and transparent object persistence is now considered mainstream. We can now focus on becoming better object modelers and avoiding Fowler's "Anemic Domain Model" antipattern, which is far too prevalent in our industry. Better, you can start today with JDO 2.0, and switch later if you want to, most likely without even changing persistence vendors, as it will be almost trivial for any JDO vendor to implement EJB 3.0 persistence.Sincerely,Matthew

Thanks Matthew. That final post may a lot more sense!

This total piece of nonsense:

"JDO's lifespan as a persistence specification is somewhat limited by the EJB 3.0 specification".

Even better:"Thus, EJB 3 might breathe new life (more life) into the JDO market..."

HAHAHAHAHAHAHAHHAHA. I've got this image in my head of a decomposing zombie-corpse stumbling forward. "Arghhh I come to breath life into you". Then I turn my flamethrower on him.

-geoff

Has anybody used this so-called workbench?

This workbench is so buggy that it is unusable.

I doubt it was ever tested :-(

Well "client side" development seems too difficult for server "side developers" ...