Java Persistent Objects (JPOX) is an Open Source implementation of the JDO1 and JDO2 specifications for transparent persistence of Java objects. The aim of JPOX from the outset has been compliance with the JDO specification(s).

JDO is still viable, despite the specification not progressing beyond 2.0 (and possibly maintenance releases), and many say that JDO's API is more powerful and more complete than the Java Persistence API's capabilities.

As well as implementing all of the mandatory parts of the JDO2 specification, JPOX 1.1 also implements the vast majority of the optional parts and provides significant extensions over the JDO2 specification. The JDO2 API and TCK are managed by the Apache JDO Project.

Some of the features provided in JPOX and in particular in version 1.1:

• Released under the Apache2 license.
• Usable with JDK 1.3 or above.
• Usage in stand-alone application, J2EE non-managed environments or J2EE managed environments (using a JCA adapter - known to work on current WebLogic, WebSphere, and JBoss servers)
• Support for schema generation, and use of existing schema, providing full control over foreign keys, indexes, candidate keys and primary keys.
• Support for both application and datastore identity.
• Numerous inbuilt identity generation strategies.
• Support for persisting a very wide range of Java types, including interface/Object fields, and many many array types.
• Support for 1-1, 1-N, M-N, uni/bidirectional, and compound identity relations supporting the full range of O/R mapping.
• Support for serialising fields.
• Support for embedding objects, embedding collections and embedding maps.
• Support for secondary tables.
• Support for attachment/detachment of objects from the persistence graph.
• Support for Datastore, Optimistic and XA transactions
• Support for persisting Java5 Enums, Oracle Spatial objects, and Oracle XMLType objects.
• User-defined fetch groups, allowing dynamic control over what is retrieved and when.
• Querying using JDOQL (including a large number of method extensions), or SQL
• JDOQL aggregates and projections.
• Support for named queries.
• Support for the vast majority of RDBMS available on the market today, including support for Views, and stored procedures.
• Significant performance improvements over JPOX 1.0
• Own byte-code enhancer providing complete JDO2 compatibility and default constructor addition (meaning there are no restrictions on user classes for JDO persistence when this enhancer).
• Pluggable framework for connection pooling with plugins for DBCP and C3P0.
• Pluggable framework for external (Level2) caching with plugins for Tangosol, EHCache, OSCache and SwarmCache
• Pluggable framework for extending JDOQL and supporting new persistent types.
• Support for Eclipse, Maven, Spring and others.
• Supported by Javelin for creating JDO MetaData.
• Supported by Elver for persistence of Eclipse EMF models.

In addition to the zero cost of JPOX and its Apache 2 license, we also provide extensive documentation, and an online support community via our Forums).

Anybody here ever seen the movie called Monty Python and the Holy Grail? Nah, I'm sure nobody here has, it's more of a nerd thing.

Anyway, there's this great scene in the movie where King Arthur fights the Black Knight. King Arthur ends up lopping off both of the Knight's arms and both of his legs, but the plucky Knight just wants to keep on fighting, never admitting defeat.

In the course of the battle, the Knight yells out all of these great catchphrases, such as "'tis but a scratch!" and "It's just a flesh wound!" and "I'm still viable, despite the specification not progressing beyond 2.0!". Ah, good times.

"Don't be such a baby and get on the cart. "

interesting...I wrote a blog on JDO over a year ago that used the same movie. I think JDO has already played it's part in the persistence drama. There is still short term value in JDO, but with most vendors supporting the new JPA standard, that's the direction things are heading.

I think JDO has already played it's part in the persistence drama. There is still short term value in JDO, but with most vendors supporting the new JPA standard, that's the direction things are heading.

Yes, it is time for JPA to play its part in a persistence tragedy.

Guido.

"Don't be such a baby and get on the cart. "interesting...I wrote a blog on JDO over a year ago that used the same movie. I think JDO has already played it's part in the persistence drama. There is still short term value in JDO, but with most vendors supporting the new JPA standard, that's the direction things are heading.

Bruce

<just a joke>
But in your case its more a question of what is better for selling your next book, whatever will be JPA or Ruby on Rails ... :)
Should we expect a book about how to recode an application that took 3 months to code with JDO in 3 days with JPA ? :)
</just a joke>

i've never had a chance to work with JDO, have you written applications in jdo and hibernate? if so, how comparable are they in terms of tools available and development productivity? is the performance as bad as hibernate?

I'm sorry but I can’t help you with that. I never used Hibernate.
After the plain JDBC, I damaged my brain a little by using EJB Entity Beans and then changed to JDO.
I have also used iBatis with great success in some projects (that already had a complex DB before the project started) and Cayenne (now an apache incubator project and one that I really like!)
Maybe someone else can answer you on that.

Pedro Costa

i love TSS

is the performance as bad as hibernate?

you should really rephrase that: "Is the performance as bad as when I use hibernate".

if you've used hibernate a lot and watched what it works you'll realise that performance isn't their #1 concern. i've used hibernate a *lot* for about 4 years and i'm well aware how performance can be improved, but there are times when it really struggles. it'll be interesting, with jpa, to see how performance differs across implementations. unfortunately, i doubt hibernate will be at the top of the pile.

apologies for the wording, i should be more diplomatic in future :$

There is still short term value in JDO, but with most vendors supporting the new JPA standard, that's the direction things are heading.

Or as in the case of KODO, they built both JDO2 and EJB3 interfaces on top of their own JPA implementation, so it's not necessarily a question of the APIs competing.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Or as in the case of KODO, they built both JDO2 and EJB3 interfaces on top of their own JPA implementation, so it's not necessarily a question of the APIs competing.Peace,Cameron Purdy

To pick a nit here, I think it's vice-versa: KODO have a JDO implementation they built a JPA interface on, if I'm not mistaken.
Peace,
Jörg

"Don't be such a baby and get on the cart. "interesting...I wrote a blog on JDO over a year ago that used the same movie. I think JDO has already played it's part in the persistence drama. There is still short term value in JDO, but with most vendors supporting the new JPA standard, that's the direction things are heading.

I disagree. JDO 2.0 is a major improvement on JDO 1.0, and is a superset of features of JPA. For example, JPA has a narrower emphasis - persistence primarily to relational stores, whereas JDO was designed to be neutral about such matters (although JDO 2.0 ORM is full-featured). My impression is that the JDO approach to this is right - other persistence mechanisms like Microsoft's LINQ also take this wider view. Also, JPA imposes significant restrictions on the objects you can persist; far more than JDO.

Most major JDO vendors are also implementing JPA, and I suspect a reasonable number of developers will take a look at the parallel JDO API and wonder why JPA - supposedly the newer API - has more limitations.

My view is that JDO's role will not be over until some future version of JPA is a closer match to JDO's feature set.

"I'm still viable, despite the specification not progressing beyond 2.0!". Ah, good times.

This is what was stated by SUN.
A survey showing figures about JDK1.3 and JDK1.4 usage would help to understand that there is a long way to go for JPA adoption.
Going beyond JDO2 ?
Well, maybe there is not so much to add to avoid its degeneration in a monster.
Maybe there will be no need for a JDO3 release.
Try to think at JAXP and SAX for example.

The facts, now, are that JDO is quite mature and runs on a POJP (Plain Old Java Platform).
JPA is at its first release and needs Java5, point.

Ah, there are the goodies.
JDO is a generic persistence mechanism. This allows you to (veeeery fast) develop your application using a pure OO JDO implementation as objectdb and then move (if you really need) to a full OR mapping one.
Without changing a bit of code.

Guido.

The facts, now, are that JDO is quite mature and runs on a POJP (Plain Old Java Platform).JPA is at its first release and needs Java5, point....

I think all readers are aware about one (you know the name) or many others (not to name them) ORM that are much more mature and (TADA!) runs on Plain Old Java Platform. I don't think it's a killer feature that will help JDO and JPOX to survive in a longer term.

Allthough I like the project, and we are using it heavily in our applications... but a desision about it wasn't made based on the "standard" or "feature" advantages.

Renat

The facts, now, are that JDO is quite mature and runs on a POJP (Plain Old Java Platform).JPA is at its first release and needs Java5, point....

I think all readers are aware about one (you know the name) or many others (not to name them) ORM that are much more mature and (TADA!) runs on Plain Old Java Platform. I don't think it's a killer feature that will help JDO and JPOX to survive in a longer term. Allthough I like the project, and we are using it heavily in our applications... but a desision about it wasn't made based on the "standard" or "feature" advantages.Renat

Many of us certainly do make decisions about things being standards. I made a decision to use JDO years ago (even though JDO 1.0 certainly had flaws) specifically because it had multi-vendor support. I have not regretted this decision. I have found that being able to potentally switch vendor is a major advantage if there are bugs or missing features in a particular implementation. In the same way that I don't want to be stuck with a particular vendor in terms of databases, I also don't want to be stuck with a particular vendor in terms of ORMs.

Theoritically speaking I'm completely agree with you. But on practice everything is much more complex. For example DB, I don't think that there are many complex, commertial, mature, applications that can easily switch between a databases.
Once I've red some discusssion about "standard" vs "innovative" topic, and I really liked some point there, I can't remember who said that but the main idea was that "standard" is really matters not when you are doing something, but when you analyzing alternatives, e.g. I need a persistence for POJO, here is a standard, first question is "if proposed solutions are the "standard" ones", and then we can go into th e details (for complex commertial applicaitions), therefore when players on the ORM fields are quite well known and features are quite the same a feature "according to standard" is less atractive anyway.
P.S. Sorry for off-topic

Theoritically speaking I'm completely agree with you. But on practice everything is much more complex. For example DB, I don't think that there are many complex, commertial, mature, applications that can easily switch between a databases.

This depends on what you mean by 'many'. The majority of applications certainly can't. One reason is that object-relational mapping systems with portable query languages are only used in a small proportion of complex, commercial database applications. However, I have seen large and highly complex applications written in JDO (and others in Hibernate) that are indeed portable.

My experience is that database portability with JDO really isn't just theoretical - it works very effectively.

oOnce I've red some discusssion about "standard" vs "innovative" topic, and I really liked some point there, I can't remember who said that but the main idea was that "standard" is really matters not when you are doing something, but when you analyzing alternatives, e.g. I need a persistence for POJO, here is a standard, first question is "if proposed solutions are the "standard" ones", and then we can go into th e details (for complex commertial applicaitions), therefore when players on the ORM fields are quite well known and features are quite the same a feature "according to standard" is less atractive anyway.

I take your point about standards, but I believe that JDO really is innovative, both in terms of its scope and implementation.

Also, I am cautious about products that are 'quite the same' rather than fully matching a specification. Switching between different JDO 2.0 products is trivial: You replace some Jars and edit a very few configuration settings. No matter how carefully you isolate things, switching between non-standard products can involve a lot of work.

P.S. Sorry for off-topic

I don't think you are!

"I'm still viable, despite the specification not progressing beyond 2.0!". Ah, good times.

That quote actually is TSS' interpretation, and not something you'll find anywhere from JDO2 or JPOX themselves, please see Andy's post further down.

For us JDO2 was not only a viable, but the only choice. Try e.g. to do replication with JPA, which doesn't allow you to specify a maximum fetch-depth when detaching an object graph. Using that, JDO2 allows us to replicate between arbitrary databases without having to resort to quasi-JDBC (something you'd have to using JPA).

JPA support by JPOX is already in the works, as it is mostly just a matter of mapping those Java-5 annotations to JDO2 metadata.

Those JDO2 and JPOX guys did a brilliant job, it's just that they produce good technology without a fuzz instead of maintaining a marketing department.

Anybody here ever seen the movie called Monty Python and the Holy Grail? Nah, I'm sure nobody here has, it's more of a nerd thing.Anyway, there's this great scene ...... yells out all of these great catchphrases, such as "'tis but a scratch!" and "It's just a flesh wound!" and "I'm still viable, despite the specification not progressing beyond 2.0!". Ah, good times.

It's funny how many of the people who seem to have issues with the 'status' of the JDO 2 specification/standard are often the same people who ruthlessly promote other persistence solutions that are either (i) standardless or (ii) ones that are standardized but nobody uses them because using them quickly becomes a wrist slashing exercise! Either standards matter to these people or they don't - they can't have a foot on both sides of the fence or they'll appear to walk around looking like someone with splinters in very sensitive places - though fortunately splitters are only a 'flesh wound'!

The way I see it JDO 2.0 came about through some of the best brains in the game designing a very clever, well architected specification for the transparent persistence of plain old java objects (POJOs) and they managed to do it in the face of tremendous political pressure to knobble it. I find it an excellent specification. They thought things through and the meta-data elements are intuitive and make sense. The meta-data elements of some other ORMs I have used have this "whoops I didn't think that before, I'd better add it now" feel to them.

I know there's often some negativity regarding "designed by committee" technologies but Craig Russell has done an excellent job and it's evident that he kept the JDO team on track and focussed. Sometimes having many good minds thinking about many possible scenarios before cementing a design in concrete is a great thing.

I believe JDO 2.0 to be a great design and specification for transparent persistence engines: I'm saying that there's two aspects to any technology: design and specification. As a software 'engineer' good design is what is paramount in my mind. EJB2's have been a 'standard' for years but a solution that didn't support inheritance didn't raise a blip on my "yeah this is a good design" radar - come on guys - you invented a standard based around the world's numero uno object oriented language, Java, and you left out support for inheritance - you were joking weren't you?

There was another part in the "Monty Python and the Holy Grail" film where you heard the clapping of horses hooves getting closer and closer. You think some knights on horseback are approaching until you see them: they're holding half a coconut shell in each hand and clapping them together to sound like horses. Not real horses just fakes - kind of like when you see a persistence technology approaching that you believe at first to be easy to use, transparent and supports POJOs and then you actually use it ...

JDO's other aspect - as a specification - is an added bonus: many companies have implemented persistence solutions according to this design/specification - which is great (and now we even have a free open source one available in JPOX!).

The fact that it's an excellent design specification for the transparent persistence of POJOs means that it's completely irrelevant what some politically influenced 'players/puppets' say about where the specification is going or it's 'status' as a specification - who cares?

The most popular ORM at the moment was never standardized or obeyed any 'community based specification/approval protocol' and never given an official blessing from those "on high" but that doesn't stop people using it.

In the same way no one should be FUDed into not using JDO 2. Shame on you. It's a great piece of software engineering design and JPOX is a great implementation of that design - but you'll only discover that when you actually use it so go ahead, make your day!

There was another part in the "Monty Python and the Holy Grail" film where you heard the clapping of horses hooves getting closer and closer. You think some knights on horseback are approaching until you see them: they're holding half a coconut shell in each hand and clapping them together to sound like horses. Not real horses just fakes - kind of like when you see a persistence technology approaching that you believe at first to be easy to use, transparent and supports POJOs and then you actually use it ...

Yes - I am not sure how many people the restrictions on the 'POJOs' that are to work with JPA: As I understand things, each class must have an identity field, the class must not be final; it can't have any final methods; it must have a non-final no-args constructor. JDO has some restrictions, which include that no method must start with 'jdo' (hardly a major issue) and a no-args constructor is needed - which can be left safely private (many JDO implementations will automatically add this for you if it is missing). JDO does a lot for you - it will automatically add identity fields and version fields for example.

My view is that this impairs the ability of JPA to work with legacy classes, whereas JDO is far more likely to be able to persist almost any class - it can probably be 'retro-fitted' to most existing code, even without the source. I think this is a significant advantage.

The types of restrictions placed on classes by JPA makes me wonder about whether the term 'POJO' is really appropriate (and I have blogged about this recently) - is a class that has to be designed, at least to some extent, with a certain framework in mind really a 'Plain Old' class, even if it has no explicit methods related to that framework?

Sorry....

Yes - I am not sure how many people understand the restrictions on the 'POJOs' that are to work with JPA

The types of restrictions placed on classes by JPA makes me wonder about whether the term 'POJO' is really appropriate (and I have blogged about this recently) - is a class that has to be designed, at least to some extent, with a certain framework in mind really a 'Plain Old' class, even if it has no explicit methods related to that framework?

No it's definitely not appropriate to say that JPA is POJO friedly if you can't take a standard Java Object model with a couple of hundred classes and just persist it without having to add special code to your source files. Now add to that the need to pollute your code with annotations and you're going back to the bad old wild west days of technology lock in - only in an open source context! Beware!

After reading the set of restrictions imposed by JPA on Java classes it looks as if JPA has been created with a certain persistence engine in mind. See if you can pick which one.

1. Must have an identity field (why? - without byte code enhancement the developer must implement identity at the source code level)
2. The class must not be final (why? - can't implement a lazy loading mechanism based on the proxy pattern)
3 It can't have any final methods (why? - proxy mechanism breaks if the superclass has a final method)

Is it just freakily coincidental that the above constraints are very similar to the Hibernate constraints? I'm sure that JPA's evolution has been untouched by the political pressures that were exerted and successfully repelled by JDO and that this is all just an amazing coincidence - what are the chances heh? Someone should go out and by a lottery ticket.

If I wasn't a cynic I would never say that it looks as if the JPA spec writers have been told, "the spec must not be so flexible and powerful that Hibernate can't support it".

I always thought the purpose of new specifications was to "advance" our industry. It looks like JDO has done this yet JPA, even though newer, has chosen to "lock in" the past instead of advancing to something better.

Here's an exercise for people who like to perform pure oo development with POJOs, without constraints and without hinderance ie., truly transparent persistence: In a popular ORM that uses proxy based lazy loading mechanism see what happens when you create a to 0..1 relationship (ie., an optional reference: a reference to an associated object may be valid or null). For example: An Employee may or may not have a HealthPlan.

In a proxy based persistence engine the test
if ( employee.healthPlan != null )
always succeeds - for all employees - even those with no health fund because the reference is the proxy - always present - even if the proxied object doesn't exist. Oh yeah and don't try to use instanceof with proxies - a very useful tool when writing assertions in JUnit tests - if you're into that sort of stuff.

JDO2 is everything you wanted JPA to be but wasn't allowed to be! Good thing you can now get hold of a top class, free, open source JDO 2 implementation in JPOX! You can use it today to persist your existing POJO object model (without any changes to your POJOs) and if you ever wanted to go to the extra effort involved in coding "down" to the JPA at some point in the future you'll be comforted to know that the good JPOX people are working on and will have no problem implementing the JPA downgrade ahem, specification.

Now add to that the need to pollute your code with annotations and you're going back to the bad old wild west days of technology lock in - only in an open source context!

I may be wrong, but I believe JPA will work fine without annotations - you can define all your metadata as XML.

JDO2 is everything you wanted JPA to be but wasn't allowed to be!

That is my view (well, I am not going to comment on the 'allowed to be', as I have no knowledge of why the expert group made the choices it did), but I would put qualify this with a stronger emphasis on JDO 2.0. JDO 1.x had some problems and omissions that had to be corrected by vendor extensions. I think this may happen with JPA 1.0.

I would put qualify this with a stronger emphasis on JDO 2.0. JDO 1.x had some problems and omissions that had to be corrected by vendor extensions. I think this may happen with JPA 1.0.

Are these vendor extensions portable ? Or just like vendor extensions to SQL ?????

I would put qualify this with a stronger emphasis on JDO 2.0. JDO 1.x had some problems and omissions that had to be corrected by vendor extensions. I think this may happen with JPA 1.0.

Are these vendor extensions portable ? Or just like vendor extensions to SQL ?????

Vendor extensions aren't generally portable. This is why SQL lacks general portability, and why I believe that much code that will use JPA implementations will often lack portability.

The advantage of JDO 2.0 is that features that were implemented as vendor extensions in JDO 1.0 have been included as required parts of the standard in JDO 2.0.

The advantage of JDO 2.0 is that features that were implemented as vendor extensions in JDO 1.0 have been included as required parts of the standard in JDO 2.0.

Yes this is a huge bonus. Now you can use a persistence technology solution that doesn't impede your object modeling in any way nor causes you to change your code/design to avoid the null semantics issues you get with proxy based non JDO solutions and still this solution provides truly transparent persistence of your POJOs and now, with JDO 2, allows for complete vendor portability.

I admit that JDO 1.0 did leave itself open to attack from FUDers who chose to claim that it was aimed purely at object oriented databases but JDO 2.0 is no longer a target for that FUD.

I think if anyone reading this was previously affected by such FUD over JDO 1.0 (like I was) they should check themselves into a FUD detox session: Simply go ahead and try JDO 2.0 by downloading JPOX - and judge for yourself. I started out using a popular proxy based persistence service and then switched to JPOX. If you're anything like me, you will be surprised at how pleasurable it is to use a well engineered solution built to a cleverly architectured specification.

I admit that JDO 1.0 did leave itself open to attack from FUDers who chose to claim that it was aimed purely at object oriented databases but JDO 2.0 is no longer a target for that FUD.

I think there is a lot of not just FUD, but honest misunderstanding of what modern ORMs (especially JDO implementations) are capable of. Years ago I was evaluating different ORMs as alternatives to raw SQL for my work in a project to upgrade legacy code based on a now-unsupported SQL dialect. There would be significant demands on the ORM - transactions involving hundreds of thousands of records, which would have to be done quickly, and without too much demand on memory. As part of my research into this I found a widespread attitude that this sort of thing should be done with SQL, and that ORM was not appropriate for such 'batch' processing, that using ORM for this sort of thing could never be efficient. However, further research revealed that even with JDO 1.0 (albeit with vendor extensions), this was entirely feasible, and so it proved with my development.

I don't mean to give the impression that I am against the use of SQL. I am a huge fan of SQL (how could anyone who had to put up with development using C and Btrieve in the mid 80s feel otherwise?). What I object to are claims that the SQL needed for serious application development is easily portable. If you don't need vendor independence, fine - go for pure SQL, but surely Java has always been about choice and portability. My view is that planning to use native SQL for a significant and increasing number of projects is a form of premature optimisation.

...As part of my research into this I found a widespread attitude that this sort of thing should be done with SQL, and that ORM was not appropriate for such 'batch' processing, that using ORM for this sort of thing could never be efficient. However, further research revealed that even with JDO 1.0 (albeit with vendor extensions), this was entirely feasible, and so it proved with my development...

Update batches are not supported with jdo. The jdoql simply lacks the ability to do so.

Try giving all your 'Users' who belong to the 'Group' foobar a raise. It simply isn't possibly without first loading the objects into the cache.

So at the moment I'm more in favor of Hibernate, since it can do such batches. The fact that JDO is a specification and makes it easy to switch between vendors is an argument of no value. How many times do you really want to switch between vendors?

Update batches are not supported with jdo. The jdoql simply lacks the ability to do so. Try giving all your 'Users' who belong to the 'Group' foobar a raise. It simply isn't possibly without first loading the objects into the cache.

That is not what I meant. By 'batch' processing I meant having the ability to handle a very large number of objects without putting excessive demands on memory. This is something good JDO implementations excel at because of the range of possible states of objects.

So at the moment I'm more in favor of Hibernate, since it can do such batches. The fact that JDO is a specification and makes it easy to switch between vendors is an argument of no value. How many times do you really want to switch between vendors?

I find it amazing how someone can say that this is of no value. Of course it is. An example is that I may initially develop and prototype with, say, JPOX, then move on to a commercial product for deployment.

I find it amazing how someone can say that this is of no value. Of course it is. An example is that I may initially develop and prototype with, say, JPOX, then move on to a commercial product for deployment.

I find it amazing how someone can use different products during dev and production. There are even differences between jdbc versions of for the same database. For that reason production and development environment should always be as closely matched as possible. That way you have the least change of unexpected behaviour.

I find it amazing how someone can say that this is of no value. Of course it is. An example is that I may initially develop and prototype with, say, JPOX, then move on to a commercial product for deployment.

I find it amazing how someone can use different products during dev and production. There are even differences between jdbc versions of for the same database. For that reason production and development environment should always be as closely matched as possible. That way you have the least change of unexpected behaviour.

You are ignoring the point of having a detailed specification like JDO 2.0. The behaviour is guaranteed. With a good JDO product, the types and versions of databases and drivers that you get this guaranteed behaviour for from their product are clearly indicated. It is up to the JDO vendor to deal with matters such as JDBC differences.

I am not saying that a developer can always switch to another database and there will be no issues at all. But JDO 2.0 allows most of those issues to be handled cleanly through the option of having database-specific ORM files (as distinct from the JDO metadata). This really does work pretty well - don't knock it until you have tried it!

I am not saying that a developer can always switch to another database and there will be no issues at all. But JDO 2.0 allows most of those issues to be handled cleanly through the option of having database-specific ORM files (as distinct from the JDO metadata). This really does work pretty well - don't knock it until you have tried it!

So to minimize the risk you usually simply stick to one product. For example, default settings whether database tables should be in lower or uppercase may differ. It isn't specified by the spec... Offcourse this behaviour can be specified using properties by most jdo products, but I can amagine there can be more tedious differences.

Forthermore, why do you assume that I haven't used JDO? As a matter of fact I'm using it at the moment for a project. I'm used working with Hibernate and I feel with JDO I'm cutting back in functionality and usability. For instance the fact that I can't do batch updates with jdo is an example of losing functionality. I'm required to write more code with jdo to achieve the same so I'm also cutting back in usability.

The only thing I gain advantage over hibernate is performance, and that is why is chosen for jdo in this project.

So to minimize the risk you usually simply stick to one product.

Sorry, but I really do disagree that there is a risk. I don't see the point in having a product (or specification) that allows portability and not making good use of that. I don't want to have to always sit connected to high-powered server running Oracle to develop.

For example, default settings whether database tables should be in lower or uppercase may differ. It isn't specified by the spec... Offcourse this behaviour can be specified using properties by most jdo products, but I can amagine there can be more tedious differences.

There can be differences, but almost all of them are handled by the particular JDO product. As I said, if a vendor lists certain databases and drivers as supported, they really have done the work for you (and if they haven't, you have a support team at that vendor who will fix things). For example, I have yet to see JDO schema-generating tool that has generated table names that have not worked on the target database.

Forthermore, why do you assume that I haven't used JDO?

I am sorry if I implied that. I was saying 'don't knock trusting JDO portability until you have tried it', not 'don't knock JDO until you have tried it'.

As a matter of fact I'm using it at the moment for a project. I'm used working with Hibernate and I feel with JDO I'm cutting back in functionality and usability. For instance the fact that I can't do batch updates with jdo is an example of losing functionality.

I agree that Hibernate is more functional in many ways, but other ways it isn't. I value the ability of JDO to persist easily to non-relational stores. I can see real uses - producing portable or read-only data sets as XML, for example, or querying LDAP.

I'm required to write more code with jdo to achieve the same so I'm also cutting back in usability.The only thing I gain advantage over hibernate is performance, and that is why is chosen for jdo in this project.

Yes, JDOQL can be more verbose. But I disagree that there are substantial usability disadvantages. I would definitely have agreed with you about this regarding JDO 1.0, but not JDO 2.0. For example, I found the omission of batch delete highly annoying in JDO 1.0.

Update batches are not supported with jdo. The jdoql simply lacks the ability to do so. Try giving all your 'Users' who belong to the 'Group' foobar a raise. It simply isn't possibly without first loading the objects into the cache.So at the moment I'm more in favor of Hibernate, since it can do such batches.

Things aren't that simple. Expressing updates in HQL is certainly cleaner than in JDOQL, but it may or may not load objects into the cache depending on other settings. If you are doing an update as part of a larger process you will want the state of in-memory objects to change.

In a popular ORM that uses proxy based lazy loading mechanism see what happens when you create a to 0..1 relationship (ie., an optional reference: a reference to an associated object may be valid or null). For example: An Employee may or may not have a HealthPlan.

In a proxy based persistence engine the test
if ( employee.healthPlan != null )
always succeeds - for all employees - even those with no health fund because the reference is the proxy - always present - even if the proxied object doesn't exist.

the null semantics issues you get with proxy based non JDO solutions

Of course proxy based implementations handles properly null semantic on one to one associations. Your claims are wrong.

the null semantics issues you get with proxy based non JDO solutions

Of course proxy based implementations handles properly null semantic on one to one associations. Your claims are wrong.If you think this claim is wrong then I suggest you get out your Hibernate PDF and have another read and maybe rework your model so it doesn't break. The Hibernate experts explain the shortcomings with lazy loaded one-to-zero-or-one relationships in this forum topic:

Hibernate forum: Problem in "one-to-zero-or-one" relationships

After using Hibernate for about 2 months this was the forum entry that made me switch to JDO.

I got offered "work arounds" to my null semantics problem like:

(i) Turn off lazy loading of one-to-one relationships - no thanks.
(ii) Refactor your model to avoid one-to-one relationships - "Hello is anyone listening? I said I wanted transparent persistence with no modeling constraints - oh yes and I do want fries with that - you do sell fries don't you?".
(iii) Turn on byte code enhancement in Hibernate - ok, so to make it work properly without constraining my modeling efforts or affecting the 'lazyness' of my object fetching I have to run it in a "imitate JDO mode": "Later dudes - I may as well just go and use JDO then".

Be prepared: Incoming FUD warning!

the null semantics issues you get with proxy based non JDO solutions

Of course proxy based implementations handles properly null semantic on one to one associations. Your claims are wrong.

If you think this claim is wrong then I suggest you get out your Hibernate PDF and have another read and maybe rework your model so it doesn't break. The Hibernate experts explain the shortcomings with lazy loaded one-to-zero-or-one relationships in this forum topic:Hibernate forum: Problem in "one-to-zero-or-one" relationships After using Hibernate for about 2 months this was the forum entry that made me switch to JDO.I got offered "work arounds" to my null semantics problem like:(i) Turn off lazy loading of one-to-one relationships - no thanks.(ii) Refactor your model to avoid one-to-one relationships - "Hello is anyone listening? I said I wanted transparent persistence with no modeling constraints - oh yes and I do want fries with that - you do sell fries don't you?".(iii) Turn on byte code enhancement in Hibernate - ok, so to make it work properly without constraining my modeling efforts or affecting the 'lazyness' of my object fetching I have to run it in a "imitate JDO mode": "Later dudes - I may as well just go and use JDO then".Be prepared: Incoming FUD warning!
Well I agree byte code enhancement is the way to go to implement AOP in Java and therefore transparent persistance. But the problem is that no true AOP language extension has made it yet to become an integral part of the Java language so there are a lot of shortcomings with the necessary extra compilation step. I'm not saying that proxy-based solutions don't have any issues either(the "instanceof" problem for instance is quite annoying) but people seem more ready to live with those. I guess this is why proxy based solution are pretty popular right now(Spring, Hibernate, ...). If only something like AspectJ could be incoporated into Java, that would be very nice and help technologies like JDO.

Well I agree byte code enhancement is the way to go to implement AOP in Java and therefore transparent persistance. But the problem is that no true AOP language extension has made it yet to become an integral part of the Java language so there are a lot of shortcomings with the necessary extra compilation step. I'm not saying that proxy-based solutions don't have any issues either
(the "instanceof" problem for instance is quite annoying)

Not to mention performance issues with proxy based solutions.

but people seem more ready to live with those. I guess this is why proxy based solution are pretty popular right now(Spring, Hibernate, ...).

If you've ever tried a byte code enhancement solution you'll wonder what all the FUD was about byte code enhancement. It's not a problem - it works fine and it's fast and the benefits it gives you far outweigh any negatives.
 
JDO's enhancement step is performed automatically by ant, maven or eclipse or whatever build tool you use and it's very quick. For me this, effectively, insignificant process beats having modelling constraints imposed on me or having to avoid certain language features: instanceof, final classes, final methods, one-to-zero-or-one relationships or having the performance hit that goes with a reflection based "dirty" object checking mechanism.

I don't want to be constantly asking myself while I'm modeling and coding whether what I'm doing is going to break my ORM or not so I'd rather just use an ORM that poses no constraints - I just code in POJOs. With JDO I can develop my whole entire POJO based object model and test it without writing a single object to a database and then, when it's working, and without any change to any POJO make the whole object model persistable.

If only something like AspectJ could be incoporated into Java, that would be very nice and help technologies like JDO.

I don't like the latest trend of wanting to pack everything into the Java language. Remember 'C' - it was so succesful and ruled the world for decades because Kerningham, Richie etal,. decided from the start that the language would be small in scope - basically: declare data structures, define functions, programming logic and implement method calls and linking. Everything else would be done in libraries. This was probably the world's oldest "separation of concerns" success story. It's simplicity was maintained because the scope of its concern was restricted from the start and kept that way.

In the same way the Java language should follow this same "separation of concerns" philosophy though lately with the introduction of annotations it seems to be losing it's way. Java's concern should just be: declaration of classes, attributes methods, programming logic and the instantiation of objects and method calls. Simple, concise - POJOs. All other concerns like persistence etc, should be kept waaaaaaaay out of the language itself. Let third party tools look after these other concerns and let the language stick to it's core responsibilities otherwise the Java language will become overly 'concerned' and too tightly coupled to various aspects of software development that it should remain blissfully ignorant of.

Perhaps eventually byte code enhancement hooks could be added to the javac compiler as way of integrating byte code enhancement (for anything that might require it, not just persistence) into the compile phase - but this should not require any changes to the language. Any byte code enhancement directives should be guided by a plug-in that hooks into the compiler at compile time. That plug-in may get info about how it enhances particular classes from a meta-data file or a database or whatever but these byte-code enhancement 'directives' should not come from language 'easter eggs' like annotations that pop up and corrupt an otherwise elegant and uncluttered language.

There is a rush of support for technologies supporting the "separation of concerns" philosophy at the coding level at the moment but to my way of thinking annotations go against this collective wisdom at a language level. I don't see how a Java class with technology specific annotations could be classed as a Plain Old Java Object - it's clearly not by definition.

Well I agree byte code enhancement is the way to go to implement AOP in Java and therefore transparent persistance. But the problem is that no true AOP language extension has made it yet to become an integral part of the Java language so there are a lot of shortcomings with the necessary extra compilation step. I'm not saying that proxy-based solutions don't have any issues either(the "instanceof" problem for instance is quite annoying)

Not to mention performance issues with proxy based solutions.

but people seem more ready to live with those. I guess this is why proxy based solution are pretty popular right now(Spring, Hibernate, ...).

If you've ever tried a byte code enhancement solution you'll wonder what all the FUD was about byte code enhancement. It's not a problem - it works fine and it's fast and the benefits it gives you far outweigh any negatives.&nbsp;JDO's enhancement step is performed automatically by ant, maven or eclipse or whatever build tool you use and it's very quick. For me this, effectively, insignificant process beats having modelling constraints imposed on me or having to avoid certain language features: instanceof, final classes, final methods, one-to-zero-or-one relationships or having the performance hit that goes with a reflection based "dirty" object checking mechanism.I don't want to be constantly asking myself while I'm modeling and coding whether what I'm doing is going to break my ORM or not so I'd rather just use an ORM that poses no constraints - I just code in POJOs. With JDO I can develop my whole entire POJO based object model and test it without writing a single object to a database and then, when it's working, and without any change to any POJO make the whole object model persistable.

If only something like AspectJ could be incoporated into Java, that would be very nice and help technologies like JDO.

I don't like the latest trend of wanting to pack everything into the Java language. Remember 'C' - it was so succesful and ruled the world for decades because Kerningham, Richie etal,. decided from the start that the language would be small in scope - basically: declare data structures, define functions, programming logic and implement method calls and linking. Everything else would be done in libraries. This was probably the world's oldest "separation of concerns" success story. It's simplicity was maintained because the scope of its concern was restricted from the start and kept that way.In the same way the Java language should follow this same "separation of concerns" philosophy though lately with the introduction of annotations it seems to be losing it's way. Java's concern should just be: declaration of classes, attributes methods, programming logic and the instantiation of objects and method calls. Simple, concise - POJOs. All other concerns like persistence etc, should be kept waaaaaaaay out of the language itself. Let third party tools look after these other concerns and let the language stick to it's core responsibilities otherwise the Java language will become overly 'concerned' and too tightly coupled to various aspects of software development that it should remain blissfully ignorant of.

I mostly agree with you except that AOP constructs should be a language level feature. Byte code enhancers are in fact just a way to implement an aspect handling some cross-cutting concerns. Proxies are another way to do it (Spring AOP, Hibernate). But aspects are basic constructing blocks to encapsulate functionnalities just as classes are so the language should provide direct support for them. At the moment, implementing AOP functionalities is like trying to do OOP using C. It is doable (using void and function pointers) but tedious and cumbersome as implementing AOP in Java using proxies or byte code enhancers.

If you want to give the power to develop normal aspects libraries that get applied at the byte code level, some AOP concepts have to be included in Java syntax. Or all those libraries will have to rely on something like CGLIB (like Hibernate when you enable it) or an extra compile step (like JDO). Note I'm not talking about aspects implementations (persistence, transactions, ...) but just the mecanism to provide them. I agree with you, implementations should be kept out the language but not the aspect model.

Perhaps eventually byte code enhancement hooks could be added to the javac compiler as way of integrating byte code enhancement (for anything that might require it, not just persistence) into the compile phase - but this should not require any changes to the language. Any byte code enhancement directives should be guided by a plug-in that hooks into the compiler at compile time.

That's exactly what an aspect is all about. You don't need a hook in the compile phase, an AOP language allows you to define those directly in your source file and ship them as normal libraries. The end user doesn't see any difference. For instance, I don't know if you are familiar with AspectJ, but here's how you define an aspect :

public aspect Persistent {
  ...
}

Quite similar to writting an class, isn't it? How easier Hibernate or JDO would be to write using those new language constructions.

Dude, do not half cut you message. I stand on my position, you're wrong:

In a popular ORM that uses proxy based lazy loading mechanism see what happens when you create a to 0..1 relationship (ie., an optional reference: a reference to an associated object may be valid or null). For example: An Employee may or may not have a HealthPlan.

In a proxy based persistence engine the test
if ( employee.healthPlan != null )
always succeeds - for all employees - even those with no health fund because the reference is the proxy - always present - even if the proxied object doesn't exist.

The test always fails (as expected). And to go further, this test actually load the object in a byte code enhancement solution like JDO. There is simply *no other way*.

Dude, do not half cut you message. I stand on my position, you're wrong:

In a popular ORM that uses proxy based lazy loading mechanism see what happens when you create a to 0..1 relationship (ie., an optional reference: a reference to an associated object may be valid or null). For example: An Employee may or may not have a HealthPlan.In a proxy based persistence engine the testif ( employee.healthPlan != null )always succeeds - for all employees - even those with no health fund because the reference is the proxy - always present - even if the proxied object doesn't exist.

The test always fails (as expected).

"You can test for null if it's not lazy." was what someone on the Hibernate team, called Emmanuel (same name might just be a coincidence), said in the Hibernate forum. Why would so many workaround's for Hibernate's issue with "null semantics of lazy loaded one-to-one relationships" be touted by official Hibernate team members in the Hibernate forum post that I referred to above if there was no issue?

Heck, if something works people normally just come out and say so - they don't throw 3 or 4 kludges/workarounds at you! You only need workarounds to workaround 'issues'. Ok so you say it works but only if you work around the issues with it - ok so let's change the definition of "works" just like we have to change the defintion of "transparent" persistence when working with Hibernate - I see the pattern here...

And to go further, this test actually load the object in a byte code enhancement solution like JDO. There is simply *no other way*.

Given that 99% of the time when I test for the existence of an object that can optionally hang off another object I'm about to do something with that very object (if it exists) so I need it loaded anyway - where's the problem?

Given that 99% of the time when I test for the existence of an object that can optionally hang off another object I'm about to do something with that very object (if it exists) so I need it loaded anyway - where's the problem?

And if this does turn out to be a performance problem, in JDO you can define a fetch group which will retrieve only the most minimal parts of the other object; perhaps nothing more than the object identity, and this can be loaded along with the original object.

"You can test for null if it's not lazy." was what someone on the Hibernate team, called Emmanuel (same name might just be a coincidence), said in the Hibernate forum.

I am this Emmanuel and I must admit this statement was pretty confusing and false taken out of its context. So let's me rephrase the whole thing when you have a lazy 0-1 association:
 - on a proxy based solution a 0-1 association will be eagerly loaded when the first object is rendered (we disable the lazy loading in this case), the null semantic will be preserved (information most likely loaded in 1 single query)
 - on a bytecode enhancement based solution (optional, but possible in hibernate), the association will eventually be loaded when the test will be evaluated (with one extra query).
 - of course you can decide to not lazy the association by applying some runtime fetching strategy with any decent ORM outthere.

And to go further, this test actually load the object in a byte code enhancement solution like JDO. There is simply *no other way*.

Given that 99% of the time when I test for the existence of an object that can optionally hang off another object I'm about to do something with that very object (if it exists) so I need it loaded anyway - where's the problem?
It was just to show you that in this case Hibernate is just as fast as any JDO implementation.

So let's me rephrase the whole thing when you have a lazy 0-1 association:&nbsp;- on a proxy based solution a 0-1 association will be eagerly loaded when the first object is rendered (we disable the lazy loading in this case)

I leave the glaringly obvious logical contradiction in the above paragraph as an exercise for the reader to discover.

Hint: I think the only confusion introduced here is when people don't use plain talking, upfront honesty. My original statement remains correct because to be perfectly honesty: the implicit "disabling of a feature" is, for all intents and purposes, equivalent to "the feature is not supported". Are you able to see this?

You're going to have to be some kind of 'king' of Hibernate techno bable if you're going to convince anyone here that an implicitly disabled feature can be regarded as a supported feature.

Of course proxies work for zero-to-one associations. What Emmanuel wanted to say is that they don't work for zero-to-one associations that are mapped with a shared primary key strategy. In that (quite rare) case Hibernate needs an additional query (or a JOIN) to determine if the associated row exists or not, to attach a NULL or a proxy.

Naturally one feature is then better disabled (proxies) and eager fetching is the default. You can enable another feature to get lazy loading behavior for zero-to-one with shared primary key, interception of association field access through bytecode instrumentation.

Interception is just not as good as proxies for general lazy loading, so Hibernate doesn't enable it by default and we recommend proxies for the 99% of associations that are not shared primary key zero-to-one's.

Of course proxies work for zero-to-one associations. What Emmanuel wanted to say is that ... [techno bable deleted]

For me, a feature either works without issues and workarounds or it doesn't. The negative airplay that many Hibernate people give byte code enhancement indicates to me that turning on byte code enhancement in Hibernate is something that brings forth the wrath of the Hibernate Gods and if not that then it at least introduces a historical philosophical contradition.

I think what you're saying is that "lazy 0-1 associations don't work in Hibernate unless you turn on byte code enhancement". This is an important issue for me and some of our customers because we extensively use the Entity-Role pattern in large enterprise models which helps massively with separation of concerns. While many Entity-Role associations are one-to-many and so work fine with proxies there are many more cases where we have one-to-zero-or-one.

As we delegate much of an entity's behaviour to it's roles a fair whack of data ends up in these optional zero-or-one roles. When loading an entity we definitely don't want eager fetching of all of the zero-or-one roles. One of the selling points of Hibernate was not having to use byte code enhancement - having to turn it on seems unnatural in Hibernate but quite natural in JDO.

Don't get me wrong - we produce a tool that supports both Hibernate and JDO meta-data generation, Javelin Model/Code/Meta-data manager, and we sell happily to both Hibernate and JDO users so I have no inherent interest in criticizing Hibernate (in fact our tool automatically generates all of the extra bits that need to be added to Java files for Hibernate persistence to make it almost transparent as JDO) but at a technical level I like to promote clean, clear unFUDed understanding of any issues I find in either technology as that is what users of Hibernate, JDO and Javelin appreciate. Clear understanding of issues helps people make better decisions and sometimes a vigorous, active discussion like this can help clear things up.

I think what you're saying is that "lazy 0-1 associations don't work in Hibernate unless you turn on byte code enhancement".

That is incorrect and clearly not what I said.

There is no other solution for shared primary key zero-to-one for lazy loading, except interception. And that requires bytecode instrumentation.

It has nothing to do with foreign key-based zero-to-one associations, which is a much more common case. Proxies work fine for that, and yes, they are better than interception - you get "hollow" objects for free.

Because there are one or two very rare things that can only be done in Java through interception code, and that interception code is best injected into the bytecode, Hibernate also got this feature one or two years ago. I hope you now understand at least one of these rare issues where bytecode instrumentation is not only appropriate, but technically the only solution.

I'm also sure you have some examples for the "extra bits" that your software needs to add for Hibernate to make it "transparent"?

I think what you're saying is that "lazy 0-1 associations don't work in Hibernate unless you turn on byte code enhancement".

That is incorrect and clearly not what I said. There is no other solution for shared primary key zero-to-one for lazy loading, except interception. And that requires bytecode instrumentation. It has nothing to do with foreign key-based zero-to-one associations.

So which case would cause the problem with null semantics as discussed and is solved by Hibernate implicitly turning off lazy loading? I just want to avoid it or possibly get the tool to perform a design critique and suggest to the user that they flick on an alternative mapping that still provides lazy loading if required.

I'm also sure you have some examples for the "extra bits" that your software needs to add for Hibernate to make it "transparent"?

Javelin automatically adds the necessary identity member as required to the most 'super' superclass. At the class diagram level this is not shown so the objects appear as POJOs without this implicit inclusion but it's added to the underlying java source in the appropriate classes.

// Implicit inclusion of identity data member and its accessors
private Long id;

private void setId(Long id) {
    this.id = id;
}

public Long getId() {
    return id;
}

It also can automatically add setters and getters as attributes are added which are required by Hibernate but users of JDO take advantage of this feature also - even though not required by JDO it's good programming practice.

It supports a whole lot of mapping directives also which aren't just Hibernate 'extras' but are handy in both worlds - like automatic unique discriminator allocation and use in the meta-data generator, project level and/or class level inheritence mapping strategies, optimistic locking strategies. The project level mapping options are handy - you can change them and regenerate all meta-data for all classes in your project to completely change the way the classes are mapped - great for quick performance comparisons.

It's actually quite feasible to switch back and forth between Hibernate or JDO mapping in about 0.5 seconds which I often think would be a great basis of a performance benchmark - exactly the same object model, with meta-data instantly rendered in Hibernate and then JDO - then you run a test. I'd love to get a real world enterprise app with 100+ classes import it into Javelin and then generate meta-data for both persistence engines and run a performance using typical real life scenarios.

So which case would cause the problem with null semantics as discussed and is solved by Hibernate implicitly turning off lazy loading? I just want to avoid it or possibly get the tool to perform a design critique and suggest to the user that they flick on an alternative mapping that still provides lazy loading if required.

The case I've described twice now, and Emmanuel before. I don't think a third time "techno babble" is helping here if it didn't so far.

Javelin automatically adds the necessary identity member as required to the most 'super' superclass. At the class diagram level this is not shown so the objects appear as POJOs without this implicit inclusion but it's added to the underlying java source in the appropriate classes.

Hibernate does not require identifier properties or fields in persistent classes. However, they are certainly recommended (there are many reasons for this, I won't try the techno babble again). But great, your tool already can create EJB 3.0 compliant entity beans, which need an identifier property or field.

It also can automatically add setters and getters as attributes are added which are required by Hibernate but users of JDO take advantage of this feature also - even though not required by JDO it's good programming practice.

This is not only a FAQ, but some myth that was never true. Hibernate does not require any particular visibility of fields, nor getter or setter methods.

like automatic unique discriminator allocation and use in the meta-data generator

By that you probably mean the use of a the fully qualified concrete class name as a discriminator value. This is how Hibernate has always done it automatically.

project level and/or class level inheritence mapping strategies

What inheritance mapping strategy is missing in Hibernate?

optimistic locking strategies

Again, what are you missing here? If you now say "Hibernate requires a version field/attribute for optimistic locking", then again: No, it doesn't.

Since the rest of your posting is about your software, and not related to Hibernate, I can't comment on that.

So which case would cause the problem with null semantics as discussed and is solved by Hibernate implicitly turning off lazy loading?

The case I've described twice now,

Ok so you're confirming that there is such a case. That's all I was trying to confirm - I was repeatedly told I was wrong in asserting that there was an issue.

and Emmanuel before. I don't think a third time "techno babble" is helping here if it didn't so far.

I'm just trying to offer a small, consise, techno bable free, paragraph of one or max two sentences that summarize the issue that someone will confirm with a "yes you've nailed it" but each time I do end up with more info. At the last iteration I believe you've added details to the effect that my choice of mapping for my zero-to-one affects whether laziness will be available (I'm all for the availability of laziness!).

I don't know if it's possible to 'nail' the issue in one or two really clear, concise sentences so that the issue could be side stepped by our users. If you could provide that clear concise summary I could stop trying and getting it wrong. Remember my aim: lazy loading of to-zero-or-one relationships with correct null semantics.

Hibernate does not require any particular visibility of fields, nor getter or setter methods.

Cool, the remaining 'extras' weren't just Hibernate specific 'extras' but stuff that both engines benefit from.

like automatic unique discriminator allocation and use in the meta-data generator

By that you probably mean the use of a the fully qualified concrete class name as a discriminator value. This is how Hibernate has always done it automatically.

My bad for the misunderstanding: what I meant was that Javelin supports the automatic allocation and management of unqiue integer based discriminators which can be used in place of the fully qualified concrete class name. Using the fully qualified name for the discriminator is a great way to get up and running fast if you have to hand code your meta-data.

Unfortunately using fully qualified names (whether Hibernate or JDO) as discriminators present you with a data migration/schema update issue whenever you rename or repackage a class. That's something we thought we could improve on given that many developers and especially the eXtreme Programmers live by the "ruthless refactoring" philosophy. We don't feel that refactoring that results in merely a class rename or repackage should render code incompatible with the existing data/schema (again this is not a Hibernate issue but a choice of disciminator issue which applies to any ORM).

To this end Javelin allocates a unique class Id to each class when it is first created in the tool. This Id is immutable over the life of the project allowing the class name or package to change without causing a change in the discriminator and hence avoid a data migration issue in all classes but the top most class in a hierarchy (obviously as we're talking discriminators we're in the context of table-per-class-hierarchy mapping strategy).

Using an unique, immutable class Id as the discriminator won't avoid data migration issues in all refactoring cases but it certainly provides a much greater scope for renaming classes (most cases) and renaming the package (all cases I believe) without data migration issues.

I suppose this strategy follows the same philosophy used in traditional DB design whereby it's preferable to create primary keys from a unique, immutable, numeric ID field instead of strings such as a person's name field or a product's name field. It provides a level of indirection that allows much greater design flexibility, allows name changes without destroying data integrity, and often provides greater performance also - especially if entites have long names - which I guess many fully qualified class names are. Smaller queries plus the database only has to do fast integer comparisons instead of slower string comparisons.

I remember doing a profile on a client's web app - the CPU was spending about 70% of it's life in methods of the String class! This was pre ORM days so I'm not making any statements about any ORM here - just a humorous discovery we made. I don't know why but for some reason somebody had gone to the effort of making an primary key ID field for each entity but then chose to give it a string type rather than a numeric type - even though no human ever saw these string IDs and only numeric data was stored in them - quite funny. I think they estimated that they would get about a 25% speed improvement merely by changing the type of their IDs. BTW: I'm in no way suggesting that using numeric discriminators gives this sort of performance gain - performance is not the motivation behind using numeric discriminators.

despite the specification not progressing beyond 2.0 (and possibly maintenance releases),

Thanks TSS editors for completely changing the submitted text, and inserting your own editorial comment. The "EJB/JDO Persistence FAQ" actually states the following :-

Q: Will there be future revisions of the JDO specification?
A: Future revisions of the JDO specification will be done as necessary to reflect the needs of the Java Community.

... so future specifications *can* be pursued (likely by Apache JDO) if the community requires them. There are plenty of satisfied JDO customers in the world who do require enhancements to their persistence needs (over JDO2) and JPA doesn't, in its current form, come close.

JPOX will follow the needs of our customers as we have since the start so if some future specification appears (whether it is called JDO3, or JPA2, or whatever) we plan on supporting it, whilst providing what real users require (and not necessarily what politics dictate).

Thanks to some companies that were key supporters to this achievement:

Nightlabs (http://www.jfire.org)
Atlassian (JIRA)
Cenqua (Clover Coverage)
SourceForge (CVS)
Ambertec
Artnology
and many others contributors and donators

http://www.jpox.org/docs/donations.html

...and a special mention to the JDO expert group for creating THE superior persistence API

I would like to give my congratulations to the JPOX Team!!
They have done a great job and they are really great supporting JPOX!

I'm a very happy JDO and JPOX user and I really think that JDO has many value on it!

JPA for me will be like JSF.... The industry leaders will push it...but most people will keep using Struts, WebWork, SpringMV C or whatever for long long time! and eventually never use JSF (I hope I will never be forced to do it myself :) )

On my case, its not even a question of choice! I will not use JDK1.5 for at least 1 maybe 2 years! I still use 1.3 in some situations and use JDK1.4.2 as a standard and I think that there are really lots of persons like me out there!

JDO2 and JPOX is something that is here and now... not something that will be on of these days (at least stable enough for me to even want to try it), and when it happens JPOX already will be updated implement the JPA specification of Java persistence (a subset of the JDO2 capabilities now)

Pedro Costa

JPA for me will be like JSF.... The industry leaders will push it...but most people will keep using Struts, WebWork, SpringMV C or whatever for long long time! and eventually never use JSF (I hope I will never be forced to do it myself :)

I know this is off topic (congratulations to the JPOX guys, by the way), but I really wish people would stop underestimating JSF; I am currently developing web applictations using facelets, MyFaces and the tomahawk components, and it is a delight to develop with. It is a vast improvement on Struts (which I used for previous work), with a rich and increasing set of components available. One of the best things about JSF is how easy it is to extend - if there is something you don't like about it, you can change it (as facelets and Seam have shown).

I think JDO and JSF have a lot in common - they are both specifications that have been hugely undervalued for too long.

Hi,
congratulations to the JPOX staff. I've used this JDO implementation on many projects have a RDBMS as back end.

For many people Hibernate seems to be the first solution, but let's try JDO-JPOX power ;-)

- Very fast
- High tuning degree
- Great support on the forum
- Very useful options to create the database schema automatically and mantain it aligned with the object model

bye,
Luca Garulli
Blogging on: http://zion-city.blogspot.com
http://RomaFramework.xwiki.com - The new way to build applications
http://www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
http://www.OrienTechnologies.com - Light ODBMS, All in one JDO solution

Why not SQL? SQL is the most portable in the world indeed.

Similar to many companies, we have to deal with several platforms including Java, VB, dot-Net and sometimes legacy applications such as Delphi. And there's no JDOQL or HQL available on VB or dot-Net at all. For our colleagues, the most productive and easiest language is SQL even on Java platform, because SQL is much more universal comparing to JDOQL/HQL. We embrace SQL and have deployed several java applications with iBatis with great success. I love SQL!

Developers abandoning SQL and going for JDOQL/HQL are actually "pulling out the flowers and watering the weeds"!

Why not SQL?
Developers abandoning SQL and going for JDOQL/HQL are actually ...

If you read the summary of features in JDO2 and in JPOX you will see that JDO2 provides JDOQL for those developers who prefer something more object-centric, and SQL for those developers who prefer that mode of working. Nobody is forcing you to abandon anything.

Why not SQL? Developers abandoning SQL and going for JDOQL/HQL are actually ...

If you read the summary of features in JDO2 and in JPOX you will see that JDO2 provides JDOQL for those developers who prefer something more object-centric, and SQL for those developers who prefer that mode of working. Nobody is forcing you to abandon anything.

If you mis-adopted JDO from beginning since JDO 1 you should have lost something, and now I don't know if you get it back. And, if we prefer something more object-centric, we should invent an "object-centric SQL" that is as portable/universal as SQL implemented by all db vendors so that we can use it in whatever platforms just like SQL, and it is certainly not JDOQL/HQL. JDOQL/HQL is simply wrong solution.

Why not SQL? SQL is the most portable in the world indeed.....

The problem is that it really isn't. Database products have always been poor at fully implementing modern SQL standards. It is possible to go some way towards portability by using a subset of SQL, but then you aren't making use of the full features and performance of the particular database.

The main advantage of JDOQL is that it is guaranteed portable, and you get all features in all implementations, no matter what the underlying database or persistence method. You even get the full functionality of JDOQL if you are querying flat files.

With JDO (and JPA, Hibernate etc.) you can potentially get better performance using a portable query language like JDOQL than with a semi-portable subset of SQL, as the JDO implementation can generate optimised SQL for the particular database you are using - you get portability and high-quality SQL.

And there's no JDOQL or HQL available on VB or dot-Net at all.

Yes there is:

http://www.hibernate.org/

"Relational Persistence for Java and .NET"

Why not SQL? SQL is the most portable in the world indeed.....

The problem is that it really isn't. Database products have always been poor at fully implementing modern SQL standards. It is possible to go some way towards portability by using a subset of SQL, but then you aren't making use of the full features and performance of the particular database.The main advantage of JDOQL is that it is guaranteed portable, and you get all features in all implementations, no matter what the underlying database or persistence method. You even get the full functionality of JDOQL if you are querying flat files.With JDO (and JPA, Hibernate etc.) you can potentially get better performance using a portable query language like JDOQL than with a semi-portable subset of SQL, as the JDO implementation can generate optimised SQL for the particular database you are using - you get portability and high-quality SQL.

And there's no JDOQL or HQL available on VB or dot-Net at all.

Yes there is:http://www.hibernate.org/"Relational Persistence for Java and .NET"

The truth is that SQL is much more portable than JDOQL. Same as databases, the JDO is implements by different vendors; you cannot guarantee the extensions implemented by different vendors are compatible. And if you use any kind of specific "added-value" features provided by any specific vendor, you get locked. This situation is same as SQL in case that you employ any specific SQL features provided by any specific db vendor. For SQL, if you stick to SQL standard such as SQL 92, you are always portable, or at least much more portable than JDOQL. For SQL, you learn once and use anywhere, you use it in Java, SQL*Plus, ISQL, VB…. For JDOQL, you simply go nowhere and can only use in Java – not portable at all. Plus, you have to put double efforts to learn query languages because, even you are java only guys, you learn JDOQL for JDO and learn SQL for SQL*Plus/ISQL. Why learn JDOQL if SQL is better?

I am extremely surprised that people just don't understand "portable".

Let's illustrate by example:
I write a SQL statement in Java, I would like to preview the result; so I copy the SQL statement to SQL*Plus and run it. This works because SQL is portable. Another example is that if I want to convert a legacy application from Delphi to Java, I can easily copy the SQL statement from Delphi to Java. This works too because SQL is portable.

For JDOQL, you go nowhere. Think about that you write JDOQL in Java, and preview result with SQL*Plus using SQL, when you get problem you just don’t know where is the problem, JDOQL or SQL? Why? It is because JDOQL is not portable.

As a result, I always recommend my colleagues to embrace SQL, and we use iBatis as a persistence framework. Maybe, there are better frameworks in the market, but embracing SQL is essential because SQL is portable and universal. Embracing SQL is not only more productive, but also improve the quality of coding especially for developers that have to deal with different kind of programming languages.

I am extremely surprised that people just don't understand "portable".

I take it to imply that you can use the same SQL universally - both in different languages and on different databases.

Another example is that if I want to convert a legacy application from Delphi to Java, I can easily copy the SQL statement from Delphi to Java. This works too because SQL is portable.

That is a very limited definition of portability, and only works if you keep to the same underlying database. This will work if you are using Delphi and Java both on Oracle or both on MySQL or both on SQL Server. Where this can fail badly if you want to change database vendor. The ability to prototype and develop primarily on a free small database engine and then complete development and deploy on a more powerful database without having to change a line of code or change a single query is an major advantage of approaches like JDO. I would not want to attempt that with SQL while also making best use of each database.

Something I really like about JDO is that it is implemented primarily as libraries and not as language extensions, so I can easily run queries and analyse results in a range of languages on the JVM. I have so far used JDOQL from within Java, BeanShell, JRuby and Groovy (although so far, my persistent classes have only been in Java, but I am looking into the possibility of using Groovy for this as well). So, it is even somewhat portable in the limited sense you are using the term.

Think about that you write JDOQL in Java, and preview result with SQL*Plus using SQL, when you get problem you just don’t know where is the problem, JDOQL or SQL? Why? It is because JDOQL is not portable.

I don't see the problem here. All JDO products I have used allow you to trace the generated SQL, so it is very easy to find out where the problem is, and I don't see how this is related in any way to portability. You can, of course, grab the SQL and preview the result in SQL*Plus. There are JDO tools that allow you to preview the JDOQL as well.....

Maybe, there are better frameworks in the market, but embracing SQL is essential because SQL is portable and universal.

No, it really isn't. As I said, no database vendor fully implements modern SQL standards. Also, SQL is only 'universal' in the sense of being a language for relational stores. JDO does not limit you to relational stores.

Of course, if you need or really want to use SQL, JDO 2.0 will allow to you use it in combination, or in place of, JDOQL.

Where this can fail badly if you want to change database vendor.

Not true! As I stated before if you stick to SQL standard such as SQL-92 you are always portable. For exmple, the JPetStore example application provided by iBATIS run happily on HSQL, MSSQL, MySQL, Oracle, Posgres ….
http://ibatis.apache.org/petstore.html

As for JDO, taken JPOX as an example, it has a supported db list. I checked the list and found that Sybase 11 is not in the list, so I can claim that JPOX is not portable to Sybase 11. Many JDO vendors has such issues. But this rarely happens to SQL.

In fact, I can list thousands examples that SQL is much more portable than JDOQL especially for cross platforms and cross developers situations. Because JDOQL is not a standard for other platforms, not a standard for DBA, not a standard for …. Example, Let said I have a poor query, and want to ask DBA for help. If the query is in SQL, I can give the SQL to DBA directly, and the DBA just gets back to me with a good query. But if the query is in JDOQL, DBA would ask what your talking about. SQL enables clear role separation of staffs in a large system, but JDOQL just make it difficult!

I don't see the problem here. All JDO products I have used allow you to trace the generated SQL, so it is very easy to find out where the problem is, and I don't see how this is related in any way to portability. You can, of course, grab the SQL and preview the result in SQL*Plus. There are JDO tools that allow you to preview the JDOQL as well.....

Take above example again, you grab the poor SQL and send to DBA, DBA give you a good SQL. Then you have to rework the JDOQL part by converting good SQL to good JDOQL. In lucky situation, your conversion will work; but if the query is complicate, after conversion, the SQL generated by JDO may still not the one you want …

Where this can fail badly if you want to change database vendor.

Not true! As I stated before if you stick to SQL standard such as SQL-92 you are always portable.

OK, this raises several points.

Firstly, why should I have to stick with a 14-year old standard?

Secondly, you are simply factually wrong about this.

Let me quote from Wikipedia:

"As a result, in contrast to ANSI C or ANSI Fortran, which can usually be ported from platform to platform without major structural changes, SQL code can rarely be ported between database systems without major modifications. There are several reasons for this lack of portability between database systems:

    * the complexity and size of the SQL standard means that most databases do not implement the entire standard.
    * the standard does not specify database behavior in several important areas (e.g. indexes), leaving it up to implementations of the standard to decide how to behave."

(I hope this makes the point clear)

Thirdly, if you do stick with a standard you can't use vendor-specific optimisations. You can get those optimisations from use of JDO, as quality implementations can recognise the database and produce specific optimisations that go beyond a restricted standard.

As for JDO, taken JPOX as an example, it has a supported db list. I checked the list and found that Sybase 11 is not in the list, so I can claim that JPOX is not portable to Sybase 11. Many JDO vendors has such issues.

This is completely missing the point about JDO. You are not tied in to one vendor's JDO implementation. The idea is not for each implementation to have to support all databases and all persistence mechanisms. You choose the implementation that supports the persistence mechanisms you want, and moving between different implementations is extremely straightforward.

The point is we aren't talking about JPOX portability - we are talking about JDO portability, and to confuse the two is as mistaken as claiming that Java is not portable to some platforms because Sun's JRE is not univerally ported.

But this rarely happens to SQL.

Sorry, but I really profoundly disagree with this. Migration between different vendors' SQL implementations for major projects has always been a significant issue. See quote from Wikipedia above.

Because JDOQL is not a standard for other platforms, not a standard for DBA, not a standard for …. Example, Let said I have a poor query, and want to ask DBA for help. If the query is in SQL, I can give the SQL to DBA directly, and the DBA just gets back to me with a good query. But if the query is in JDOQL, DBA would ask what your talking about.

You need to look further at what JDO can do. As I explained, you can log the SQL that is produced in order to tune your queries. If you really need to use SQL, you can use SQL, and store that query externally for optimisation and to allow switching to a different optimised query for a different database.

SQL enables clear role separation of staffs in a large system, but JDOQL just make it difficult!

No it doesn't. JDO can use either externalised SQL or JDOQL queries that can be optimised separately from the main development process.

Take above example again, you grab the poor SQL and send to DBA, DBA give you a good SQL. Then you have to rework the JDOQL part by converting good SQL to good JDOQL. In lucky situation, your conversion will work; but if the query is complicate, after conversion, the SQL generated by JDO may still not the one you want …

No, you don't. If there is the rare case where you need a tailored SQL query, you can keep that as SQL, and separate from the code.

SQL code can rarely be ported between database systems without major modifications

I have gave you example that SQL is portable, please read me previous post.

You are not tied in to one vendor's JDO implementation.

But you are tied to JDO. The elegance of SQL is learn once use anywhere, any platforms and any languages!

The point is we aren't talking about JPOX portability - we are talking about JDO portability

JPOX is a sample of non-portable JDO. Simply do an survey, and tell me how many percentage of JDO implementations support aged stores such as Sybase 9, Interbase 4.5 and MS SQL 6.5 ? You will know how non- portable JDO is ? This is fact!

JDOQL queries that can be optimised separately from the main development process.

I am afraid that no DBAs speak JDOQL. For SQL, you simply copy the statement from your application to DBA, then DBA works with the SQL with his/her favorite DB clients (this works because SQL is portable), then give you an optimized SQL, and you simply replace your SQL with optimized one. Is JDOQL portable enough to run on DBA’s favorite DB client ?

I have gave you example that SQL is portable, please read me previous post.

You have given no example, you simply stated it as fact. Sorry, but I simply don't believe you. It isn't my personal experience and I am sure it isn't the experience of many others reading this.

But you are tied to JDO.

No, you aren't. JDO is simply one way to generate SQL. There is nothing to stop you using JDO in some Java/JVM applications and raw SQL in others accessing the same database.

The elegance of SQL is learn once use anywhere, any platforms and any languages!

If only that were true. It would be great if it was. But as anyone with experience of major database products will tell you, learning the details of a specific SQL dialect, all the data types available, all the indexing and contraints available

JPOX is a sample of non-portable JDO.

Sorry, but this statement just doesn't make sense.

Simply do an survey, and tell me how many percentage of JDO implementations support aged stores such as Sybase 9, Interbase 4.5 and MS SQL 6.5 ? You will know how non- portable JDO is ? This is fact!

This makes no sense in terms of SQL support either. There are major SQL dialect differences between these.

There are individual JDO products that can guarantee that their product supports full and identical JDOQL on over a dozen commercial and open source database. This means you can write absolutely identical full-featured queries and have them work on all these databases.

For those of us (like me) who have been dealing with the horrors of SQL dialect differences since the 80s, this is an enormous benefit.

JDOQL queries that can be optimised separately from the main development process.

I am afraid that no DBAs speak JDOQL.

Then, as I have said, for the things that need heavy optimising, use SQL from within JDO. The amount of query coding that needs such optimising is almost certainly minimal.

For SQL, you simply copy the statement from your application to DBA, then DBA works with the SQL with his/her favorite DB clients (this works because SQL is portable)

You keep stating this, in the face of evidence. I quoted a Wikipedia entry describing why SQL is not portable. Don't believe it?

OK, here is more evidence:

http://builder.com.com/5100-6388-1046268.html

"Six years ago, NIST stopped enforcing the ANSI/SQL standard, rendering it ineffective and largely ignored due to a lack of accountability for compliance."

http://www.hibernate.org/382.html

Check out the ways that SQL Server 2005 deviates from the ANSI standard!

Here is a nice one:
http://phplens.com/lens/adodb/tips_portable_sql.htm

"Most database vendors practice product lock-in. The best or fastest way to do things is often implemented using proprietary extensions to SQL. This makes it extremely hard to write portable SQL code that performs well under all conditions."

However, I feel that all this is rather redundant - it is stating the totally obvious.

What I object to are claims that the SQL needed for serious application development is easily portable.

OK. I give you a public available examples embracing SQL, and please tell me it how it can be more portable by embracing JDOQL.
http://ibatis.apache.org/petstore.html

Simply do an survey, and tell me how many percentage of JDO implementations support aged stores such as Sybase 9, Interbase 4.5 and MS SQL 6.5 ? You will know how non- portable JDO is ? This is fact!

This makes no sense in terms of SQL support either. There are major SQL dialect differences between these.

Many JDO implementations are simply totally not workable on such aged stores. The portability of JDO is of theory, but practically not for these situations.

There are individual JDO products that can guarantee that their product supports full and identical JDOQL on over a dozen commercial and open source database. This means you can write absolutely identical full-featured queries and have them work on all these databases.

Do you mean one has to use multiple JDO implementations in order to make their applications "portable" to these databases ?

Then, as I have said, for the things that need heavy optimising, use SQL from within JDO.

If SQL is evil and making your projects failed, you should eliminate it all together just like JDO1. Give me some hints about why JDO2 allows SQL? Because some guys are not evolutive enough to use JDOQL ? or because SQL is far better than JDOQL ?

However, I feel that all this is rather redundant - it is stating the totally obvious.

The most obvious point is that JDOQL is not portable among platforms, not understandable among people. The most redundant part is that developers waste their time to learn and use JDOQL. Developers speak JDOQL in their JDO applications, has to switch to SQL when they talk to dba, when they use SQL*Plus, when they codes scripts … even turning out that they are dealing with exactly same Query. This inconsistency is not only redundant but also error-proning and unproductive.

The most obvious point is that JDOQL is not portable among platforms, not understandable among people. The most redundant part is that developers waste their time to learn and use JDOQL. Developers speak JDOQL in their JDO applications, has to switch to SQL when they talk to dba, when they use SQL*Plus, when they codes scripts … even turning out that they are dealing with exactly same Query.

And using SQL to map a relationnal table structure to an object structure is an easy task? One point you don't seem to get, JDOQL or any OBJECT oriented query language is not a fork of SQL but a layer to add the necessary object concepts to allow the conversion of a relational model to an object model. SQL can't adress this concern since it is a RELATIONAL query language. It force you to do all the mapping manually. That's the price you have to pay if you stick to regular SQL and that's why iBatis necessitate so much configuration. The ORM tools authors didn't invent new languages just for the sake of portability but it is a very nice and welcome secondary effect.
Here's a nice article on the subject :
http://www.developer.com/java/ent/article.php/3322131

So what is more performant learning a new language quite similar to SQL or performing the mapping manually all over your application ?

And like I said most people live with the generated SQL in most cases except some queries that need to be optimised. So your argument when they use SQL*PLUS is not very good, most developers I know of rarely use an SQL tool anymore. They stick with Hibernate IDE or some JDO tools to test their queries.

This inconsistency is not only redundant but also error-proning and unproductive.

Are you serious? Most developers I know have seen a tremendous productivy ugprade using an ORM tool.

Here's a nice article on the subject :
http://www.developer.com/java/ent/article.php/3322131

The nice article is of HQL. Can I speak HQL in JDO applications ? Both JDOQL and HQL are not portable, I mean it is not a common language comparing SQL which is widely adopted. This causes problem when I give an JDO application to a developer with Toplink background. How many query languages should the developer learn ?

And like I said most people live with the generated SQL in most cases except some queries that need to be optimised.

True ? I think all JDO1 people live with generated SQL.

Are you serious? Most developers I know have seen a tremendous productivy ugprade using an ORM tool.

ORM tool is not necessary redundant and unproductive, but JDOQL is absolutely redundant. I have had emphasized this point:

The point is that we need a query language that is really standard & universal, we can use it in any languages such as Java, VB, C++, ect, we can use it in various environments such as inside applications, consoles, db clients (e.g. SQL*Plus), it should be portable between people (common language) so that DBA understands what developer talks, so that new developers switch from other programming languages don't have re-learn a new query language. And the answer is SQL! And JDOQL is not portable at all by our definition.

I am glad that JDO 2 developers finally can speak SQL. Good job! It is good that we can communicate with English (though my English is not good, I implement the "English standard" poorly), and you don't have to learn my mother-tongue language. The world is beautiful with a common language!

Can I speak HQL in JDO applications ?

If you need and you like an opensource JDO product you can
write yourself a parser.
Anyway this statement is like this:
Can I speak JDOQL in PL/SQL application ?

I think all JDO1 people live with generated SQL.

Thinking about things never experienced is, unfortunately,
a widely spread practice.
Try to speak about porting the SQL applications from one
DB vendor to another.

ORM tool is not necessary redundant and unproductive, but JDOQL is absolutely redundant.

I think you miss a point. SQL deals with RDBMS, it deals
with TABLEs and COLUMNs, point.
I think you know, but objects are not tables.
Common SQL syntax simply does not fit the needs of querying an object oriented model.
JDO is not a specification for ORM implementations.
JDO2 has standardized the mapping syntax for ORM implementations, so you can switch across JDO ORM vendors quite easily.
There are a LOT of JDO implementations that are not, or not only, ORM solutions:
ObjectDB
Gemsone Facets
ObjectStore
JDOInstruments
XCALIA
OrientTechnologies

FYI, I have ported (oops, this is not portability for you)
an application, without changing a bit of code, from an ORM
JDO implementation to a pure OODBMS one.

At the end, there are tons of publications about this topic.
Not to suggest readings, but I have found rather useful Scott Ambler (www.ambysoft.com) writings about persistence, ORM, and much more.

BTW, if you have a wonderful PRO*C application do you really think that porting it to VB or Delphi is just a matter of
Copy&Paste the SQL statement with an editor ?

Guido

If you need and you like an opensource JDO product you can
write yourself a parser.
Anyway this statement is like this:
Can I speak JDOQL in PL/SQL application ?

I do believe that someone would write a parser. Given multiple ORM tools and multiple ORM-QLs in the market now, soon there will be whatever parsers so that developers from JDO background can speak JDOQL in Hibernate applications, and developers from EJB background can speak ejb query in JDO applications. And soon or later someone will step forward to develop an abstract on top of all ORM tools, it's called commons-orm.jar. At that time, I keep going on speaking SQL, and you stick to JDOQL, while someone is speaking HQL, others are speaking whatever.

We are repeating our experience of web frameworks. Is this a flexibility ?

Thinking about things never experienced is, unfortunately,
a widely spread practice.
Try to speak about porting the SQL applications from one
DB vendor to another.

I do have great success with SQL-centric projects. And I also listed in my previous post of a public available SQL-centric Petstore application, you can check whether JDO versions are more portable than this SQL-centric version.

There are a LOT of JDO implementations that are not, or not only, ORM solutions:
ObjectDB
Gemsone Facets
ObjectStore
JDOInstruments
XCALIA
OrientTechnologies

Sorry for my lack of experience of enterprise applications on such data stores.

FYI, I have ported (oops, this is not portability for you)
an application, without changing a bit of code, from an ORM
JDO implementation to a pure OODBMS one.

Congratulations!

BTW, if you have a wonderful PRO*C application do you really think that porting it to VB or Delphi is just a matter of
Copy&Paste the SQL statement with an editor ?

If you already have a cross-platform, cross-people query language, and you can use this query language in PRO*C, VB, Java, SQL*Plus and whatever, and you can speak this query language to your dba and other developers. Then it doesn't make senses to invent JDOQL where there's no acceptance except in JDO. And the worst thing is that every ORM tool invent its own ORM-QL.

At that time, I keep going on speaking SQL

I guess you mean SQLs (please note the 's').

I do have great success with SQL-centric projects.

Congratulations!
But, sorry, it means nothing:I do have great success too with JDO-centric projects.
And everybody is happy.

Sorry for my lack of experience of enterprise applications on such data stores.

Noone is perfect. But was not this the point. But you seem
 to miss it, don't know if deliberately or not.
JDO is not designed to be an ORM solution only, I hope you catch the difference. Assumed this, SQL is not an option and an object oriented persistence framework WITHOUT a query language solves less than an half of the problem.
BTW, just stay tuned, what is an enterprise application (you know, there is a certain difference in our vocabulary - portability, for example) ?

Anyway, I should desume from your missing answers that:
1. There is no big difference between an object class and a TABLE.
2. Porting an application from VB to Delphi to whatever is just a matter of Copy&Paste SQL statements.

Guido

Assumed this, SQL is not an option

Actually, it is :)

From the JPOX site:

"The JDO 2.0 specification requires that implementations provide a SQL query mechanism (for datastores that support SQL)."

But you are right, it is really not appropriate for SQL to be the only option for an API that goes beyond ORM.

Many JDO implementations are simply totally not workable on such aged stores. The portability of JDO is of theory, but practically not for these situations.

And you are saying that SQL standards are workable on them? Not my experience.

There are individual JDO products that can guarantee that their product supports full and identical JDOQL on over a dozen commercial and open source database. This means you can write absolutely identical full-featured queries and have them work on all these databases.

Do you mean one has to use multiple JDO implementations in order to make their applications "portable" to these databases ?
No. There are single products that can do this.

Then, as I have said, for the things that need heavy optimising, use SQL from within JDO.

If SQL is evil and making your projects failed, you should eliminate it all together just like JDO1.

Who is saying that SQL is evil? All I am saying is that SQL standards are poorly implemented so that SQL is not portable.

Give me some hints about why JDO2 allows SQL? Because some guys are not evolutive enough to use JDOQL ? or because SQL is far better than JDOQL ?

Because no one technology is suitable for all purposes, and because there may well be substantial legacy SQL code that you want to use as part of your development.

However, I feel that all this is rather redundant - it is stating the totally obvious.

The most obvious point is that JDOQL is not portable among platforms, not understandable among people. The most redundant part is that developers waste their time to learn and use JDOQL. Developers speak JDOQL in their JDO applications, has to switch to SQL when they talk to dba, when they use SQL*Plus, when they codes scripts … even turning out that they are dealing with exactly same Query. This inconsistency is not only redundant but also error-proning and unproductive.

You are missing the point about the way modern ORMs like JDO work. You don't need to learn substantial amounts of a new query language, because the majority of database access is entirely transparent.

You are also neglecting something obvious about JDOQL: There is virtually nothing for a Java developer to learn, as JDOQL is basically Java.

Steve,

I believe netbug has some excellent points. My issue with any QL from the Java layer is that the space is quite fragmented. You've got Hibernate's HQL, EJB 2.x, 3.x's EJBQL, UML's OCL, JDO's JDOQL - all of which are similar but not portable amongst one another. Not counting of course vendor extensions to the "QLs" because the spec is usually limited.

People shift database implementations less often than they do AppServer implementations - at least in my experience. So, if your argument is one of "XYZ-QL provides full database portability", that just doesn't hold with me.

On the other hand, if you are building a commoditized version of a product that has a requirement of running on multiple databases, I can understand some of your points. (For e.g. look around for packaged/3rd party J2EE components Are there many? Do they support all AppServers and all databases?)

Your points:

"You are missing the point about the way modern ORMs like JDO work. You don't need to learn substantial amounts of a new query language, because the majority of database access is entirely transparent.

You are also neglecting something obvious about JDOQL: There is virtually nothing for a Java developer to learn, as JDOQL is basically Java."

Might hold for simple applications that need little more than "SELECT ... FROM CUSTOMERS" or "SELECT ... FROM CUSTOMERS c, ORDERS o), but for a majority of serious enterprise applications, a java developer needs to know a serious amount of SQL. For example, how do you query a multi-gigabyte database efficiently? What tradeoffs do you need to make with queries, locking, concurrency, transactions, isolation levels?

Your statement that "database access is transparent" can be misleading. I do not have a problem with transparency. But transparency != "I can ignore it". If you do not exactly know what your ORM layer (be it JDO, EJB, Hibernate) is doing with the database, and details of its interactions, you are setting yourself up for a failed project.

Also your last part about "JDO QL is Java" is wrong. Treating it as one will lead to Java developers bringing in object graphs and processing them without a care in the world.

-krish

<blockquoteMy issue with any QL from the Java layer is that the space is quite fragmented. You've got Hibernate's HQL, EJB 2.x, 3.x's EJBQL, UML's OCL, JDO's JDOQL - all of which are similar but not portable amongst one another. Not counting of course vendor extensions to the "QLs" because the spec is usually limited.
That is the point of having rich standard query systems like JDO 2.0, which include as part of the spec things that have formerly been vendor extensions.

People shift database implementations less often than they do AppServer implementations - at least in my experience. So, if your argument is one of "XYZ-QL provides full database portability", that just doesn't hold with me.On the other hand, if you are building a commoditized version of a product that has a requirement of running on multiple databases, I can understand some of your points.

We have different experiences. I shift database implementations frequently, and find the ability to do this very useful indeed. I can do most of my development on an open source database which does not require substantial resources, then deploy on a higher-powered commercial product, having confidence that my JDO product will generate high-performance SQL on each. I can present full-featured demonstrations of my applications using a small Java database on my notebook PC.
Might hold for simple applications that need little more than "SELECT ... FROM CUSTOMERS" or "SELECT ... FROM CUSTOMERS c, ORDERS o), but for a majority of serious enterprise applications, a java developer needs to know a serious amount of SQL. For example, how do you query a multi-gigabyte database efficiently? What tradeoffs do you need to make with queries, locking, concurrency, transactions, isolation levels?Your statement that "database access is transparent" can be misleading. I do not have a problem with transparency. But transparency != "I can ignore it". If you do not exactly know what your ORM layer (be it JDO, EJB, Hibernate) is doing with the database, and details of its interactions, you are setting yourself up for a failed project.Also your last part about "JDO QL is Java" is wrong. Treating it as one will lead to Java developers bringing in object graphs and processing them without a care in the world.-krish
Of course a Java developer needs to know a serious amount of SQL - it is one of the most important tools in IT. But nothing you have described in the above paragraph has anything to do with use of SQL or not, and you are setting up a lot of false impressions about what JDO is about and how it works.

Firstly, JDO 2.0 has a very rich API, both for querying and for the handling of transactions, concurrency, locking and so on. JDOQL is certainly not limited to simple select statements - you should take a look at the JDOQL specification (JPOX have great documentation on their site).

As for transparency in JDO, that is nothing whatsoever to do with ignoring things. It has a very specific meaning - I don't need to explicitly fetch and persist all the persistence-capable objects I that I am dealing with. All I need to do is retrieve (for example) one object, and if I access persistence-capable objects referenced by that origical object, they are automatically retrieved for me. This process can either involve 'lazy loading', or the retrieval can be highly optimised using JDO fetch groups and plans.

Why is this useful? Firstly because it allows a clean separation of concerns - you don't need persistence logic in your business code. Secondly because it allows persistence to be easily retro-fitted to legacy code, even if the source is not available.

And as for JDOQL, all I was saying was that its syntax is easy to understand for Java developers. There is no reason why this syntax should lead to inefficiency. JDO has powerful features for tuning how and when objects are retrieved and a rich relational mapping specification.

JDO can be highly efficient - I am routinely using it for large batch processes where individual transactions involve hundreds of thousands of records.

The amount misunderstanding about what JDO is, how it works, and what it can do seems endless!

OK. I give you a public available examples embracing SQL, and please tell me it how it can be more portable by embracing JDOQL.

http://ibatis.apache.org/petstore.html

You have actually provided an example which is an excellent illustration of why JDO is more portable than SQL.

That petstore project includes SQL for creating schemas and inserting data. It includes them for five databases, because the SQL is different for those databases. Pick a typical JDO product and for products like that petstore you only need one set of source files; one .JDO file; one set of JDOQL queries. The schema tools have built-in knowledge of what DDL to automatically generate.

[Also, you should take a look at the iBatis documentation. There a significant number of items in the FAQ dealing with vendor-specific SQL issues, such as date format problems issues in different Oracle versions.]

So, I don't need to show how JDO/JDOQL is more portable - you have already done it for me with this example.

In fact, this is a useful example for illustrating other benefits of JDO; note the simplicity of the queries included with the demo. This is necessary, for portability. Try and do anything more even slightly more complicated and you lose this portability.

Let me show you a simple example of how JDOQL can help with this. Suppose you want to access the first 10 chars of a string and then removing leading and trailing whitespace. Simple enough in JDOQL:

"string.substring(0,10).trim()"

That will work anywhere.

Now let's try it in Oracle SQL:

"trim(substr(string,1,10))"

Looks OK, doesn't it? The problem is that it isn't portable. For MySQL you need:

"trim(substring(string,1,10))"

For SQL Server you have to write:

"ltrim(rtrim(substring(string,1,10))"

For three widely used databases, we need different SQL even for something as simple as this.

So how does JDO deal with this? JDO products have knowledge of the different SQL dialects. They convert the same JDOQL to those different SQL strings.

Best of all, they will generate optimised SQL. You could be reasonably portable, at least with the trimming, by writing "ltrim(rtrim(string))", but that is inefficient on databases that have a single "trim" function. JDO products will use such a single function if it is there.

It is possible to transform SQL or JDOQL query string to the same "native" SQL query string. There are many free SQL parser, driver adapter implementations and there are no technical problems to transform query strings, but it looks like nobody cares about this "problem" in practice.

It is possible to transform SQL or JDOQL query string to the same "native" SQL query string. There are many free SQL parser, driver adapter implementations and there are no technical problems to transform query strings, but it looks like nobody cares about this "problem" in practice.

I think the debate here shows that many people definitely do care about this problem, and there are a very large number of resources and products devoted to the problem of database SQL migration, and the process still isn't simple.

But anyway, one feature of JDO is that you aren't always transforming to native SQL. Another feature is that you don't have to choose and between driver adapters and SQL parsers and porters - why bother when the JDO implementors have not only done the work for you?

JDO is not just for relational stores, and it is also an API for transparent persistence. You don't get that with SQL alone.

...parse ResultSets!

Or do they prefer to parse raw bytes.

This increasing level of abstraction is surely headed for failure ;-)

Where this can fail badly if you want to change database vendor.

Not true! As I stated before if you stick to SQL standard such as SQL-92 you are always portable. For exmple, the JPetStore example application provided by iBATIS run happily on HSQL, MSSQL, MySQL, Oracle, Posgres …. http://ibatis.apache.org/petstore.htmlAs for JDO, taken JPOX as an example, it has a supported db list. I checked the list and found that Sybase 11 is not in the list, so I can claim that JPOX is not portable to Sybase 11. Many JDO vendors has such issues. But this rarely happens to SQL.In fact, I can list thousands examples that SQL is much more portable than JDOQL especially for cross platforms and cross developers situations. Because JDOQL is not a standard for other platforms, not a standard for DBA, not a standard for …. Example, Let said I have a poor query, and want to ask DBA for help. If the query is in SQL, I can give the SQL to DBA directly, and the DBA just gets back to me with a good query. But if the query is in JDOQL, DBA would ask what your talking about. SQL enables clear role separation of staffs in a large system, but JDOQL just make it difficult!

I don't see the problem here. All JDO products I have used allow you to trace the generated SQL, so it is very easy to find out where the problem is, and I don't see how this is related in any way to portability. You can, of course, grab the SQL and preview the result in SQL*Plus. There are JDO tools that allow you to preview the JDOQL as well.....

Take above example again, you grab the poor SQL and send to DBA, DBA give you a good SQL. Then you have to rework the JDOQL part by converting good SQL to good JDOQL. In lucky situation, your conversion will work; but if the query is complicate, after conversion, the SQL generated by JDO may still not the one you want …

Well you are assuming everyone use a bottom-up approach while most people using ORM frameworks use top-down approach. By the way, ORM frameworks don't forbid you to use a bottom-up approach, you are still free to use plain native SQL (and makes Hibernate or JDO act like iBatis) and not JDOQL or HQL. Just most people think the top-down approach has more merits in desgning enterprise applications.

We are not talking about bottom-up, down-top or middle-out .......

The point is that we need a query language that is really standard & universal, we can use it in any languages such as Java, VB, C++, ect, we can use it in various environments such as inside applications, consoles, db clients (e.g. SQL*Plus), it should be portable between people (common language) so that DBA understands what developer talks, so that new developers switch from other programming languages don't have re-learn a new query language. And the answer is SQL! And JDOQL is not portable at all by our definition.

So one should embrace SQL no matter which persistence framework (JDO, Hibernate, iBatis) one choosed. Non-portable query languages such as JDOQL should be avoided. JDOQL is a backslide of query language.

Where this can fail badly if you want to change database vendor.

Not true! As I stated before if you stick to SQL standard such as SQL-92 you are always portable. For exmple, the JPetStore example application provided by iBATIS run happily on HSQL, MSSQL, MySQL, Oracle, Posgres …. http://ibatis.apache.org/petstore.htmlAs for JDO, taken JPOX as an example, it has a supported db list. I checked the list and found that Sybase 11 is not in the list, so I can claim that JPOX is not portable to Sybase 11. Many JDO vendors has such issues. But this rarely happens to SQL.In fact, I can list thousands examples that SQL is much more portable than JDOQL especially for cross platforms and cross developers situations. Because JDOQL is not a standard for other platforms, not a standard for DBA, not a standard for …. Example, Let said I have a poor query, and want to ask DBA for help. If the query is in SQL, I can give the SQL to DBA directly, and the DBA just gets back to me with a good query. But if the query is in JDOQL, DBA would ask what your talking about. SQL enables clear role separation of staffs in a large system, but JDOQL just make it difficult!

I don't see the problem here. All JDO products I have used allow you to trace the generated SQL, so it is very easy to find out where the problem is, and I don't see how this is related in any way to portability. You can, of course, grab the SQL and preview the result in SQL*Plus. There are JDO tools that allow you to preview the JDOQL as well.....

Take above example again, you grab the poor SQL and send to DBA, DBA give you a good SQL. Then you have to rework the JDOQL part by converting good SQL to good JDOQL. In lucky situation, your conversion will work; but if the query is complicate, after conversion, the SQL generated by JDO may still not the one you want …

Well you are assuming everyone use a bottom-up approach while most people using ORM frameworks use top-down approach. By the way, ORM frameworks don't forbid you to use a bottom-up approach, you are still free to use plain native SQL (and makes Hibernate or JDO act like iBatis) and not JDOQL or HQL. Just most people think the top-down approach has more merits in desgning enterprise applications.

We are not talking about bottom-up, down-top or middle-out .......

The point is that we need a query language that is really standard & universal, we can use it in any languages such as Java, VB, C++, ect, we can use it in various environments such as inside applications, consoles, db clients (e.g. SQL*Plus), it should be portable between people (common language) so that DBA understands what developer talks, so that new developers switch from other programming languages don't have re-learn a new query language. And the answer is SQL! And JDOQL is not portable at all by our definition.

So one should embrace SQL no matter which persistence framework (JDO, Hibernate, iBatis) one choosed. Non-portable query languages such as JDOQL should be avoided. JDOQL is a backslide of query language.

Where this can fail badly if you want to change database vendor.

Not true! As I stated before if you stick to SQL standard such as SQL-92 you are always portable. For exmple, the JPetStore example application provided by iBATIS run happily on HSQL, MSSQL, MySQL, Oracle, Posgres …. http://ibatis.apache.org/petstore.htmlAs for JDO, taken JPOX as an example, it has a supported db list. I checked the list and found that Sybase 11 is not in the list, so I can claim that JPOX is not portable to Sybase 11. Many JDO vendors has such issues. But this rarely happens to SQL.In fact, I can list thousands examples that SQL is much more portable than JDOQL especially for cross platforms and cross developers situations. Because JDOQL is not a standard for other platforms, not a standard for DBA, not a standard for …. Example, Let said I have a poor query, and want to ask DBA for help. If the query is in SQL, I can give the SQL to DBA directly, and the DBA just gets back to me with a good query. But if the query is in JDOQL, DBA would ask what your talking about. SQL enables clear role separation of staffs in a large system, but JDOQL just make it difficult!

I don't see the problem here. All JDO products I have used allow you to trace the generated SQL, so it is very easy to find out where the problem is, and I don't see how this is related in any way to portability. You can, of course, grab the SQL and preview the result in SQL*Plus. There are JDO tools that allow you to preview the JDOQL as well.....

Take above example again, you grab the poor SQL and send to DBA, DBA give you a good SQL. Then you have to rework the JDOQL part by converting good SQL to good JDOQL. In lucky situation, your conversion will work; but if the query is complicate, after conversion, the SQL generated by JDO may still not the one you want …

Well you are assuming everyone use a bottom-up approach while most people using ORM frameworks use top-down approach. By the way, ORM frameworks don't forbid you to use a bottom-up approach, you are still free to use plain native SQL (and makes Hibernate or JDO act like iBatis) and not JDOQL or HQL. Just most people think the top-down approach has more merits in desgning enterprise applications.

We are not talking about bottom-up, down-top or middle-out .......The point is that we need a query language that is really standard &amp; universal, we can use it in any languages such as Java, VB, C++, ect

You are when you say things like :

Take above example again, you grab the poor SQL and send to DBA, DBA give you a good SQL. Then you have to rework the JDOQL part by converting good SQL to good JDOQL. In lucky situation, your conversion will work; but if the query is complicate, after conversion, the SQL generated by JDO may still not the one you want …

it should be portable between people (common language) so that DBA understands what developer talks, so that new developers switch from other programming languages don't have re-learn a new query language.

This is a bottom-up approach, in a top bottom approach you trust the ORM to do the good thing and live with the good and bad parts of the generated SQL. Except some few exceptions, you don't touch the generated SQL and use JDOQL or HQL everywhere.

it should be portable between people (common language) so that DBA understands what developer talks, so that new developers switch from other programming languages don't have re-learn a new query language. And the answer is SQL! And JDOQL is not portable at all by our definition.

So one should embrace SQL no matter which persistence framework (JDO, Hibernate, iBatis) one choosed. Non-portable query languages such as JDOQL should be avoided. JDOQL is a backslide of query language.

You are miking things here. You are right SQL is supported by more languages. Why? Because basically the language (Java, C#) knows nothing about SQL. It just takes the SQL Query you write and spit it out to the DB then collect the results. JDBC is all about connecting to the DB and sending the query to the DB in a correct way, not about interpreting and manipulating the query. It's the DB responsability to interpret SQL. So it's true, SQL is more portable across technologies because SQL doesn't have to be interpreted to be used. It is the DB native language.

HQL or JDOQL are at a higher level then SQL, they add a layer on top of SQL since they map objects field to table fields and generate SQL queries. Hence to use those kind of query languages, your technology need to parse and interpret HQL or JDOQL queries. Those languages just move some responsabilities out of your application and let the frameworks handle them. Using a pure SQL approach, it's you application responsability to map your objects fields to table fields (programmatically or declaratively) and to take care of the famous impedance mismatch.

The question is : Is it worth it to add this indirection layer or should you handle it manually all across your application ? I think the indirection layer is truly worth it! It gives you a portability advantage across DB and a true object oriented query language that handle the mapping between your objects and table fields. But at the same time you loose the power of *speaking* directly to the DB when you use them. Each approach has it advantages but most of the times I prefer to use a ORM query language because of the higher abstractions I get.

As for JDO, taken JPOX as an example, it has a supported db list. I checked the list and found that Sybase 11 is not in the list, so I can claim that JPOX is not portable to Sybase 11. Many JDO vendors has such issues. But this rarely happens to SQL.

For the record that is wrong. JPOX docs only list the RDBMS that we have had time to add to the docs to say that are known to work. We are most of the time 2 people writing a JDO implementation. We don't say we "support" particular RDBMS. I personally have used Sybase 11 with JPOX, a long time ago, and had no issue at all. I don't add it to the docs since that was with an old version of JPOX and I don't have access to that RDBMS now. JPOX provides, as do all popular ORM mappers, the wrapper to cover over the unportability of SQL between the many RDBMS around. No, not all "in production" RDBMS support the full SQL-92. ORM's provide the portability.

Look, you can use SQL, you can use JDOQL, you can even use a mixture in the same application if you so wish. It's called flexibility. Get over it and move on.

you can even use a mixture in the same application if you so wish. It's called flexibility.

It's called dirty, while you can use SQL only!

I always recommend my colleagues to embrace SQL, and we use iBatis as a persistence framework. Maybe, there are better frameworks in the market, but embracing SQL is essential because SQL is portable and universal. Embracing SQL is not only more productive, but also improve the quality of coding especially for developers that have to deal with different kind of programming languages.

Ugh. This mentality is one of the reasons why so many enterprise software projects fail. (Coincidentally, I'm speaking on this topic at JavaOne. It's titled "The Top Ten Ways to Botch an Enterprise Java Application".)

From my experience, most failures in enterprise software projects are caused by decisions made on dogma instead of pragma, and most of those bad decisions are around data access and data modeling.

While your points are absolutely correct in some contexts (I agree that SQL is an excellent choice for certain classes of applications), it is the ability to ignore the contextual differences between applications that causes fundamentally self-defeating architectural decisions to be made.

Of course, there are dogmatic proponents of various Hibernate, EJB, JDO and OODBMS products that suffer from the same syndrome ;-)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

I always recommend my colleagues to embrace SQL, and we use iBatis as a persistence framework. Maybe, there are better frameworks in the market, but embracing SQL is essential because SQL is portable and universal. Embracing SQL is not only more productive, but also improve the quality of coding especially for developers that have to deal with different kind of programming languages.

Ugh. This mentality is one of the reasons why so many enterprise software projects fail. (Coincidentally, I'm speaking on this topic at JavaOne. It's titled "The Top Ten Ways to Botch an Enterprise Java Application".)From my experience, most failures in enterprise software projects are caused by decisions made on dogma instead of pragma, and most of those bad decisions are around data access and data modeling.While your points are absolutely correct in some contexts (I agree that SQL is an excellent choice for certain classes of applications), it is the ability to ignore the contextual differences between applications that causes fundamentally self-defeating architectural decisions to be made.Of course, there are dogmatic proponents of various Hibernate, EJB, JDO and OODBMS products that suffer from the same syndrome ;-)Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

Agree! The example is the transformation of Entity Bean from “Design Pattern� to “Anti Design Pattern�. The dogmatic proponents of Entity Bean may have failed thousands of projects. While the JDO proponents from beginning of JDO 1 have failed a dozen.

Agree! The example is the transformation of Entity Bean from “Design Pattern” to “Anti Design Pattern”. The dogmatic proponents of Entity Bean may have failed thousands of projects. While the JDO proponents from beginning of JDO 1 have failed a dozen.

Apart from the fact that you seem to have missed the point of this post, I would not be surprised if there are substantial numbers of failed EJB projects. It seems to be the nature of current IT that for any given technology a significant proportion of projects fail. I am sure there are countless projects involving native SQL that have failed as well.

However, I think it is time to put and end to your FUD. I think it is time you backed up your claims with evidence. JDO vendors can list substantial numbers of successful projects and reference sites. Perhaps you could provide real evidence that JDO projects fail more than those using any other technology?

Ugh. This mentality is one of the reasons why so many enterprise software projects fail.

This mentality greatly contributes too -

clear role separation of staffs in a large system

Ok, it is YOUR choice, you CAN use SQL with JDO 2.0 if you think it is so important

I am extremely surprised that people just don't understand "portable". Let's illustrate by example:I write a SQL statement in Java, I would like to preview the result; so I copy the SQL statement to SQL*Plus and run it. This works because SQL is portable. Another example is that if I want to convert a legacy application from Delphi to Java, I can easily copy the SQL statement from Delphi to Java. This works too because SQL is portable.For JDOQL, you go nowhere. Think about that you write JDOQL in Java, and preview result with SQL*Plus using SQL, when you get problem you just don’t know where is the problem, JDOQL or SQL? Why? It is because JDOQL is not portable.As a result, I always recommend my colleagues to embrace SQL, and we use iBatis as a persistence framework. Maybe, there are better frameworks in the market, but embracing SQL is essential because SQL is portable and universal. Embracing SQL is not only more productive, but also improve the quality of coding especially for developers that have to deal with different kind of programming languages.

Database products have always been poor at fully implementing modern SQL standards. It is possible to go some way towards portability by using a subset of SQL, but then you aren't making use of the full features and performance of the particular database.

On the contrary, modern databases does implement a reasonable set of SQL which enables SQL's universal usage, and more portable than JDOQL.

For ORM, there is no standard (or multiple standards) in the market. There are many ORM tools namely JDO, Entity Bean, Toplink, EJB 3 and Hibernate, different ORM may provide different ORM-QL, so that someday in the future when one of them (or a new ORM tool such as Universal-DO) wins the market, all others will left in pain.

Maybe, some clever guys will create a abstract layer to leverage all kinds of ORM tools so that their applications are really portable. Or some clever guys will invent a query language translator (called QLT) so that developers from Hibernate background can speak HQL in JDO applications, or developers from JDO background can speak JDOQL in Hibernate application.

Database products have always been poor at fully implementing modern SQL standards. It is possible to go some way towards portability by using a subset of SQL, but then you aren't making use of the full features and performance of the particular database.

On the contrary, modern databases does implement a reasonable set of SQL which enables SQL's universal usage, and more portable than JDOQL.

And why can't the the JDOQL implementation benefit from that as well? If it hasn't fully optimized support for you database it can ALLWAYS generate this portable SQL don't you think?

Cheers
 JD

And there's no JDOQL or HQL available on VB or dot-Net at all.

NHibernate anyone?

The earth is still round, despite the Flat Earth Society having limited future publications of the matter. Many say that a round earth might enable more convenient forms of navigation.

Thank you Captain Obvious!

:-) It's always heartwarming to see how the persistence layer continues to have people show the back of their tongue! I love TSS, it's like a market but better: without the fish, and with the shouting.

A few thought as I was browsing thru the many remarks:
1/ As for performance, the remark on Hibernate being slow is justified (cf http://www.jpox.org/docs/performance.html - would be interesting to see how JPOX final & Hib 3 compare too)

2/ As for JPA ... what's the fuss? JPA is just an API and I guess all persistence implementations will sooner or later conform to it. All of them. My best guess: Hib will be first, JDO will be best, and EJB worst. (at least they respect tradition!) The true value is I think for devs; for app developers migrations will be much easier, for project Mgrs (should they care) comparisons much more objective. But most implementations will be a big superset of it. JPA ... is in fact a minimal JDO3 (begging for FUD here ;-)

3/ I'd be interesting to see the true intrinsic value/superiority of JDO grow, now that the spec is met and it has passed TCK. Like:
3.1/
JDO is DS transparant. (This is -to me- the single biggest party pooper of Hibernate: you're stuck with relational DBs, what's the fun in that?) JPOX is build to include e.g. XML persistence equally easy. How great would that be, you (mostly) work with XML too, but now you only need one component to manage the 2, instead of 2. (It's becoming a fetish of mine, I would really like to see a merge of JibX & JPOX - they're both awesome at what they intend and have already so much in common) You write an additional mapping file (1 per DS) and you filter the very same Domain Model to e.g. get the data for a webservice.
3.2/ JSR 170 & 283: Content Rep Mgmt... One ring to bind them all. :-)
RDBMS, LDAP, XML, ... Wouldn't it be very interesting when people could just use this for "all" their DS access + services on top (Tx, versioning - a lot of what JDO offers already). It surprises me (unless I'm missing smth) this doens't get more tongue. Perhaps in the future.

4/ (<off topic>) As for JSF: people should stop complaining & start looking at all the great components of MyFaces/Tomahawk/Sandbox/ADF/... It's impressive. Admittedly without these components JSF is using a Boeing for a walk in the parc, and agreed, it took 'm a while to develop some awesome stuff, but they're there. Patience is rewarded. (</off-topic>)
Sorry JPOX - I'll leave the stage back to you guys. Very cool job.

 & I'll very curious to what's next. JDO's here to stay. (No matter how Sun wishes to label it.)

Peace,
Philippe

As for JPA ... what's the fuss? JPA is just an API and I guess all persistence implementations will sooner or later conform to it. All of them.

That is what the fuss is about. JPA seems to be being positioned as 'the' standard API for Java persistence, with a widely held view that now that JPA is here, JDO is no longer required. There has been an effort to 'unify' JDO and EJB specifications. I hope that JPA 1.0 is not supposed to be the final stage of that process, and that future versions will include more JDO features (and features from other more powerful persistence APIs as well).

The future of JPA lies in the API features it adopts. (or... not)
If it embraces the cool features of all persistence FWs, and learns from the mistakes of EJBs (that includes v3 I'm afraid) it'll live.
 
If not, I'm afraid it'll continue to have a parallel underground-kinda life.
You'll see stuff like: "oh yeah that's true, btw we also conform to JPA." (in font pt 5, somewhere underneath the page footer of as a hidden field so that only Google sees it ;-)

As opposed to: "We are fully JPA conform + offer (follow the distinctive features)
- bla and
- bli and
- blu"

1/ As for performance, the remark on Hibernate being slow is justified (cf http://www.jpox.org/docs/performance.html - would be interesting to see how JPOX final &amp; Hib 3 compare too)

This is the same useless benchmark that we have seen for years, so you can just replace the word "STORM" with "Pole Position", and re-read what has already been said a thousand times: http://hibernate.org/Documentation/Benchmarks

Nobody who knows Hibernate wants to spend time on this again just to prove how ridiculous the test methodology is and how useless the results are. (Actually, AFAIK Anthony spent an hour on Pole Position after everybody else turned it down already and he got the same fun results we know from STORM and others... with Hibernate being 10x faster than anything else. Right.)

In the end, TSS gets a few more page views and banner ad impressions out of this kind of discussion - and isn't that all we care about?