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 28

Hibernate 3 Released

Java, ORM, Tech 6 Comments »

Hibernate 3 has been released, with good timing around the JBossWorld conference.

It is good to see the 3.0, which has features I am interested in… mainly:

  • More flexible mappings for the times in which I can’t quite get Hibernate 2 to do what I need.
  • Hibernate3 filters
  • Unchecked exceptions
  • Hibernate Tools
  • Second-level cache browser
  • XML integration

Now we need to test the hell out of it, and see what version is ready for production. You can’t expect Hibernate 3.0 to be as production ready as the mature 2.x branch which is battle worn.

Many congrats to the Hibernate team.

Full Release Notes

Hibernate 3.0 is the world’s most sophisticated ORXM
(Object/Relational/XML Mapping) solution. Hibernate3 makes it easier
than ever before for Java applications to interact with persistent
data, allowing a single definition of the transformation between
various in-memory representations of the entity data and the relational
schema, even in the case of very complex legacy schemas and schemas for
historical data or data with visibility rules. Hibernate3 also provides
the most comprehensive object/relational query functionality, with
three full-featured query facilities: Hibernate Query Language, the
newly enhanced Hibernate Criteria Query API, and enhanced support for
queries expressed in the native SQL dialect of the database.

Compared to Hibernate 2.1 – the most popular object/relational mapping solution in any language – Hibernate 3.0 offers:

  • Much more flexible O/R mapping: support for exotic association and
    inheritance mappings, and greater flexibility when working with legacy
    data.
  • Hibernate3 filters: a unique feature for working with temporal (historical), regional or permissioned data.
  • Unprecendented flexibility for mixing handwritten and generated SQL
    within a single application or even a single entity: full support for
    “derived” entities and attributes defined in the mapping document, full
    support for overriding any generated SQL statement with handwritten
    SQL, support for stored procedures.
  • Object/Relational/XML mapping: query XML directly from the database
    for reporting, replicate data between databases via intermediate XML,
    externalize entity data as XML when interacting with remote systems.
  • Enhanced ease of use: better defaulting, an unchecked exceptions
    model, simplified natural (and composite) key support, simplified CMT
    integration.
  • Enhanced Criteria query API: with full support for projection/aggregation and subselects.
  • Runtime performance monitoring: via JMX or local Java API, including a second-level cache browser.
  • Brand new AST-based HQL parser: bulk update/delete enhancement, better syntax validation.
  • JBoss EJB 3.0 preview: support for annotation-based O/R mappings,
    full support for EJB-QL 3.0, support for EJB 3.0 persist()/merge()
    lifecycle, JACC-based security model.
  • Hibernate Tools preview: a full suite of Eclipse plugins for
    working with Hibernate 3.0, including mapping editor, interactive query
    prototyping, schema reverse engineering tool.
  • Many new extension points: including a new, extensible, event-driven architecture
  • Documentation enhancements.
  • Brand new test suite, including many useful examples of exotic Hibernate mappings.
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 =)

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