Apr 19

Versant offers their JDO/EJB3 implementation to Eclipse

JDO No Comments »

Versant is giving JDO 2.0 and EJB 3.0 to Eclipse.

I think this is a smart move for them, as their business model isn’t to make money on an ORM, but selling OODMBS, and other OR solutions.

Now there are quite a few implementations (Apache JDO, JPOX, etc), and other vendors are doing cool licenses for the community.

When JDO 2.0 and EJB 3.0 are both final drafts, we will see some very cool runtimes and tools to work with.

More power in the fight for Vietnam (as Ted says).

Mar 01

JDO 2.0 Review receives a positive result in the voting

JDO, Java, ORM, Tech 1 Comment »

This is great news. After the debacle of the first round of voting, today we had the revote.

Many expected that the initial vote was the death of JDO, but this have thankfully been proven to be premature and false.

There was a large outcry from those inside the JDO community, and even those that are external to it. From talking to the EC after the vote, it was apparant that the “NO” voters were not actually voting against JDO, rather against the timing (around xmas), not knowing about how it fits with the JSR 220 persistence spec, and the process in general.

Kudos to the JCP EC, who listened to the community, and then made their decision.

The different thoughts are shown in the comments:

Regarding the letter, and the JSR 220 agreement

Intel: voted Yes

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.

SAP: voted Yes

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.

Regarding the process

Intel: voted Yes

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.

Abstainers

Last time around, I felt that some of the EC should have voted ‘Abstain’ rather than ‘No’. This time, the abstains have come in as veiled No votes, and strongly try to put across the message of “I guess we will allow the tiny JDO community continue while we take on the world” :)

JBoss: Abstained

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.

Oracle: Abstained

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.

Favourites

Of the votes, I think my favourite has to be:

Apache Software Foundation: voted Yes

Let a thousand flowers bloom :)

BEA: voted Yes

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.

Vote Results

Yes (12)

  • Apache
  • BEA
  • Borland
  • Doug Lea
  • Fujitsu
  • Google
  • HP
  • IONA
  • Intel
  • Nortel
  • SAP
  • Sun

Abstain (3)

  • JBoss
  • IBM
  • Oracle

UPDATED NOTE: Apple didn’t vote as the EC member was on vacation :)

Time to move on

Now it is time to move on. JDO 2 can continue its great work. We can work with the EJB team to help out there too, and everyone is a winner.

See the results of the vote

Feb 02

‘Nam is not over yet Mr. Box ;)

JDO, ORM, Tech 18 Comments »

Don Box put up a link in his blog saying:

A Single Victory in ‘Nam

Richard Monson-Haefel on the end of JDO.

I respect RMH, but think (and really hope) he is way off base on this one.

One of the problems is that since he was on the EC before he left to become an analyst at Burton, that he has some inside scoop on the voting.

On this topic, he doesn’t have a clue ;)

I have actually be speaking to the EC about the vote, and, unless they are totally B.S.ing me (which is always possible), I am feeling really good that the vote will be ratified in the correct way. There is even an Online petition, and many letters to the EC including a letter from a huge Chinese portal showing their JDO usage and how it would affect them not to have JDO 2.0.

As long as bad politics doesn’t provail, I will be happy to say “thank god RMH and Don Box don’t know what they are talking about” ;)

Jan 31

TheServerSide now running on Tapestry/Kodo JDO

JDO, Java, ORM, Tech, Web Frameworks 2 Comments »

TheServerSide communities are now running on Tapestry on the front end, and Kodo JDO for the data access.

We had known for awhile that it was ready for a change, and it was an interesting experience choosing what we wanted to port TSS over too.

There are many great web frameworks, and data solutions, but we definitely ended up happy with what we got.

The port was done in record time, in no part thanks to having Howard Lewis Ship on the team. If you are ever doing a Tapestry project, you owe it to yourself to bring him in for a bit. Not only does he obviously know Tapestry inside and out, but he is just a top class developer which great ideas!

Looking at the before and after version of TheServerSide is very interesting. Now TSS has a great, component-based version which is easy to extend. Before, it was always a fight to change / add anything.

It also doesn’t hurt that the site is faster and more stable than ever before. Kodo JDO has been top notch on that scale, and it has the solid Tangosol Coherence under the scenes as the distributed cluster technology.

Read more: How TSS Converted to Tapestry

Jan 20

Richard Monson-Haefel proclaims JDOs death, but it is premature!

JDO, ORM, Tech No Comments »

RMH has proclaimed: The death knell: The JCP EC rejects JDO 2.0.

Although JDO 2 may not get voted through. It isn’t dead yet. All you have to do is look at the TSS thread to see how people feel about it.

I still have hope that some of the guys that voted ‘No’ (those who don’t have a real political motivation to kill JDO) will come around. I think there has been a mixup in the process, and people need to communicate better. It also didn’t help that this all happened over a winter holiday so, some people feel like they didn’t have the required time to feel like they could say ‘Yes’ (although I would prefer an abstain like Google).

I also think that RMH is wrong when he says:

I believe that the EJB 3.0 POJO persistence model will become pluggable so that you can choose your persistence provider separate from your J2EE vendor.

Take a look at the EJB 3 early draft. This is NOT in scope! The vendors claim that ‘users have not asked for this’ in EJB. I agree with RMH 100% that we SHOULD have a pluggable implementation of the persistence manager / entity manager / whatever it ends up being called in the final EJB 3. Without it we get the same lockin that we have now. JDO has allowed us the freedom to change implementations, and NOT be locked in like this, and it will be a sad day if we lose it. Sad enough to make some nice folks say ’screw it’ and pick up Ruby even more :)

Jan 19

AspectJ/AspectWerkz. JDO 2.0 Ballot Results. The good and the bad.

AOP, JDO, Java, ORM, Tech No Comments »

The top two posts on TheServerSide are:

  • AspectJ and AspectWerkz Merge Forces
  • JDO 2.0 Public Review Ballot

These give a glimpse at the good and the bad side of the Java community.

On the ‘good’ side we have the AOP news. Here we have two communities coming together for the greater good of the overall community. There isn’t the politics, nor the egos of “my app is better than yours”. They got together and talked about how they could work together and end up with a merger which is going to change AOP forever.

On the ‘bad’ side we have the JDO 2.0 ballot news. Here we have politics getting in the way. There are JDO users who are desperate to get JDO 2.0 implementations into their hands. They need it to take care of their business. Take a look at the vendors who went against the spec, and those who are for it.

I was optimistic, yet worried at the same time, about the EJB 3 / JDO 2 news that came out. It appears that some people are using that news as a way to hold back the JDO 2 spec. A lot of people have spent a LOT of time on that work, and our users deserve it right now.

P.s. I really liked Aslak’s quote regarding the AOP merger:

Forking seems to be more common than merging in the OSS world. This is great news. I wish you good luck.

Dec 07

Apache adopts new JDO project

JDO, Java, ORM, Open Source, Tech 355 Comments »

The Apache DB group voted on a new JDO proposal. The new proposal spells out a place for some serious JDO work to happen.

It has been brought together with leaders in the Apache, other open source, and JDO worlds:

  • Abe White, SolarMetric, JDO expert group member
  • Brian McCallister, OJB committer
  • Craig Russell, Sun, JDO Specification Lead
  • Dain Sundstrom, GlueCode, Geronimo committer
  • Erik Bengtson, JPOX committer
  • Geir Magnusson, GlueCode, Geronimo committer
  • Michael Bouschen, JDO expert group member
  • Michelle Caisse, Sun, JDO TCK developer
  • Patrick Linskey, SolarMetric, JDO expert group member
  • Victor Kirkebo, Sun, JDO TCK developer

There are six initial subprojects envisioned:

  • JDO 1.0 API
  • JDO 1.0 Reference Implementation
  • JDO 1.0 Technology Compatibility Kit
  • JDO 2.0 API
  • JDO 2.0 Technology Compatibility Kit
  • JDO 2.0 Geronimo integration

I witnessed a lot of good talk at ApacheCon, and I am happy to hear that it is coming to fruition. With these fine blokes behind it, I am hopeful for a top notch JDO implementation with an Apache brand.

Someone already asked “Doesn’t OJB support JDO?” to which Brian McCallister replied:

OJB supports a JDO interface via a plugin to the JDO 1.0.X reference implementation (which is SCSL, non-commercial variant) so is basically useless right now. This same RI is part of the initial codebase for this project, so the OJB JDO 1.0.X interface can actually become useful =)

Sep 25

JDO and EJB join forces: The cat is out of the bag

EJB, JDO, Java, Tech 5 Comments »

The official announcement will come out of Sun on Monday, but the cat is out of the bag.

Firstly lets look at the facts:

  • A new spec/RI/TCK is being created UNDER the JSR-220 (EJB3) umbrella
  • This new spec will be based on the persistence API from the EJB 3 early draft
  • The scope is for a persistence API for BOTH J2SE and J2EE (so it will work outside of a container)
  • JDO experts have been invited to join the EJB team to grow it from here
  • The final spec will be available in the same time frame as J2EE 5
  • The JDO 2.0 spec will continue. It will now add the ability to externalize JDO-QL so it can be used from the new persistence API

I am really hopeful with this situation. A lot of the folks on the JDO camp are NOT all about JDO… they just want a transparent persistence model that isn’t stuck in a container. Now it looks like this is going to happen, and the EJB folk are on board too. If this is done right then it will be a huge win for everyone.

Although I am really excited about the potential, the proof WILL be in the pudding, and I have a couple of concerns:

Where it lives

In my mind there were three options for placing a spec which holds a persistence API for J2SE and J2EE:

  1. JDO: Since this spec kinda has that mandate already, it could have lived here. A reason for doing this would be that there are already users of this API. A reason for not doing this is that there are already users of this API.
  2. EJB 3: It seems a little strange to have a spec that covers J2SE in an EJB spec umbrella, but they have done work on this themselves. I would argue that more work has been done with JDO 2, but hey, let’s move on
  3. New JSR/Group: I know it would have taken more time to come up with a new JSR, but I would have ideally wanted this. A new group would have been formed and it would have set the tone to be a brand new collaboration. As it stands some people are skeptical that the JDO folk will be listened too. I am really hoping that everyone gets their say and that we get a great spec.

Pluggable Persistence

EJB specs have always talked about the idea of a Persistence Manager, and hinted that at some time this will be pluggable. JDO specs have had this notion from the beginning.

I *really* like the fact that JDO plays nice with the J2EE CA, so I can deploy whatever persistence manager I want by throwing a RAR at my application server. This seems like a no brainer on what it should be.

I want to be able to run WebLogic Server with IBM’s persistence manager. Well, I don’t really want that combination, but I want the flexibility.

From what I have heard on the grapevine, the new persistence API may not have the pluggable contract which really bugs me.

Why wouldn’t they define this? The only reason in my opinion is that application vendors don’t want this as they obviously want lock-in.

Please, please, please open up and allow the best persistence managers to fight it out in the market.

Finish on a positive note…

Overall I am really excited on this new bold move from Sun. Kudos to them for getting together and working out that this makes sense for the community. I really hope that in practice this works out and we get a great persistence API that everyone is happy with. My few worries above are only mentioned in the vein hope that people think about these things and we do the right thing.

Let’s get to work!

Update:

Jason has good comments:

Any idea if it’s still going to be dependent on 1.5 with annotations? And are those annotations going to be defined and jar’d in the j2ee.jar? Will I have to compile against the j2ee.jar or a vendor jar and either ship with the j2ee.jar or deploy in a container just to get the annotation classes?

I really hope that since this sub-spec is meant to target J2SE, that there is no need to ship j2ee.jar. Surely!

Jun 23

Comparing JDO, EJB, Hibernate, and Amber

EJB, JDO, Java, Tech 1 Comment »

Scott Ferguson has written a simple blog entry that compares JDO, EJB/CMP, Hibernate and Amber.

He has simple Pro’s and Con’s for the various solutions and manages to keep it 100% technical. He stays away from the politics. Nicely done.

Regarding some of his comments:

  • I don’t want my OR mapper to be passing around java.sql.ResultSets. I want to work with objects!
  • JDO-QL may not be perfect, but in JDO 2 you can use other languages, such as SQL itself (but anything that you want/the vendor allows!)
Jun 08

Listen to Geir: Persisting Problems

EJB, JDO, Java, ORM, Tech No Comments »

I just saw Geir Magnusson Jr. and Jeremy Boynes entry discussing the problem that we have with persistence at this moment of time.

I have personally written about this before here, here, and here.

But back to the blog from Geir and Jeremy. The go through the problem at hand, and notice that we all want the same thing:

Give me a transparent persistence API

It looks like we can agree on that. So then the next question is how do we get to that path.

It seems like a no-brainer to me that we should use JDO 2.0 to get there, but I am of course biased. JDO shouldn’t only be in J2EE, it should be in J2SE in my opinion. You know, sometimes I want to access a data source WITHOUT being in an enterprise environment! I definitely want to do this without having to have an EJB container.

It is great to hear this from some of the Apache guys, and I look forward to us all coming together to work on the same problem. If we got in the same room we would find out that having blue eyes or brown eyes don’t matter. We both see.

Persisting Problems