A homepage for Java Data Objects (JDO) has been finally placed on java.sun.com. The page contains the usual description and links, as well as two FAQ's about how JDO is related to JDBC/EJB. The FAQ's do not directly mention that JDO can be used as an alternative to entity beans. I guess its still not politically correct to say that. :)
Check out the JDO Homepage at:
The FAQ infact mentions that JDO could be used behind the data access object pattern (behind a session facade). That sounds like a silly idea. Why hide your pure java object model behind clunky DAO's with CRUD operations? DAO's improve over plain JDBC code, but they definitly don't improve over a nice object model that is transparently persisted by a JDO engine.
Did you send your comment to : mailto:jdo-comments at sun dot com
Does anyone know about some (at least semi-objective) evaluation? Comparison to say CMP?
Which is the best available free implementation of JDO?
There are very few really free JDO implementations. A few of them have decent licensing terms for development, and even possibly for non-commercial use. But there isn't much in the space of purely free JDO.
ObjectBridge (OJB) is part-way there, but their JDO implementation, at this point, is somewhat lacking. I'm hoping they'll get there. In the meantime, OJB via ODMG is a reasonable option. I hope the open-source and/or free software world will expand further into JDO space with time. There are certainly other attempts in progress, but nothing even remotely close to completion, AFAIK.
If anyone knows of exceptions to the above, please, feel free to correct me.
There are at least two other opensource JDO projects: TJDO
seems to be a conventional JDO implementation while XORM
is being developed so that no bytecode enhancement is necessary. Both projects are coming along, but I don't believe either yet implements the entire JDO spec.
Of course, there's always the JDO-like open source OR system Castor
. Just be aware that code developed with Castor is not portable to true JDO implementations.
As an aside, why is it that for nearly every article on this site some sort of Microsoft FUD creeps into the discussion? Are we as java developers so insecure about the future viability of java the platform that we have to keep looking over our shoulders at the phantom bill-of-goods that Bill, Steve and their minions are foisting on the world?
There is a jakarta proyect (Object Relational Bridge) that is going to implement the JDO http://jakarta.apache.org/ojb/index.html
I've used EJB CMP 2.0 (with JBoss), OJB, Apple WebObject's EOF, and KODO JDO. JDO wins hands down. CMP is out, OJB is not mature, there were a few unsolved bugs with 1:n relations that no one would acknowledge, and EOF was a joke. JDO was the easiest to get working (took 2 days to persist a whole chunk of my object model) and has been working great since.
If you want a very lightweight and truly transparent persistence (none of my objects changed at all when I moved to JDO) then JDO is a good choice. The KODO tutorial is easy to set up and run. They have a free 30 or 45 day license.
Also as another poster mentioned, there is no need to use a DAO pattern with JDO. JDO is the opposite of DAO.
After J2EE had been in use for some time the concept of "J2EE Patterns" emerged. What many people fail to realize is that many of the so-called "J2EE Patterns" exist to mitigate problems inherent in the J2EE architecture.
JDO, as a transparent persistence infrastructure which is not intrusive to the domain object model, solves many persistence problems that previously plagued J2EE developers. Thus the use of JDO minimizes or eliminates the need for patterns such as these, including DAO.
Kind regards, Robin.
The Blogging Roller blog recently posted a great chart on open O/R-Mapping implementations for Java. Only one fully supports JDO, but the chart is still very informative.
<q Russ >
Thanks for link. I am not sure how to add comments to blogger. Anyway:
--Toplink now is Oracle product
Now it provides jdo interface also with full
utilization of TopLink's own query functionality.
As a O/R mapper TL can do all 4 scenario
from table. Only LGPL and SF activity will
--BC4J is poverful tool and extends now to
one-click generation of struts-based screens
with edit, create, delete ,view details, paging...
I do not like BC4J creates new database tables for
transactional control. IMHO, database schema is
more important than any code that use it.
Clean database schema/data is what outlive
all mappers-shmappers all together :-)
-- there is simple bottom-to-top OR mapper
With bitmechanic's connection pool and
some JTA it works perfectly. GNPL.
Last release 2 years ago.
When I was a SQL DBA I believed the mantra was to have a clean Data Model, which could then support all current application requirements and be extended to support future requirements also.
That was some time ago.
Now I am an object modeller. I believe that the mantra is to have a clean domain object model. Such a model supports all current application requirements and can be extended to support future requirements also. But by working at the object level, instead of the data level, I believe that the resulting model lends itself well to exploitation through OO environments, specifically Java.
With JDO I can finally do this effectively.
Before JDO I had to constrain my domain object models in order for the developers to be able to persist them reliably. Typically pre-JDO projects had a component (perhaps 30% or more) that represented the creation or configuration of some persistence infrastructure. All of that effort has now been made unnecessary.
And this is within a vendor-neutral, and indeed paradigm-neutral standard. I'm impressed!
Oh, and one more thing. My clients can now build systems without having their deployment architecture and future technology adoption strategies dictated by their DBMS vendor...!
Kind regards, Robin.
I belive clean data model is better(*) than clean domain model in bigger part of various applications.
(*) better == long-run cost
Domain evolves with time. It is easy to add/modify
new entity into any OO model, but hard to migrate
data in _bad_ db schema. A domain will be absolete
in several years, data will be never absolete
[...for most applications].
And about dbms lock - there are always some locks:
MS, BEA, Struts, Oracle, Java (!), citizenship,
...fata morgana of freedom...
Have a good week,
Just wanted to correct a mistake in one of the posts. You can oick up an evaluation copy of FrontierSuite for JDO 3.0 from our site. The evaluation period is 30 days. And the version available is the enterprise edition.
S Rajesh Babu
I agree with Robin 100% that a clean domain model that models the persistent data of the application is a better driver and controller of the persistence data. Though the 'domain' model evolves over time, it is a much better place to drive your application from than the counter-intuitive way of driving it from the data(base) layer. And if the domain model does evolve, that would most probably involve a change in the way data is stored (I do not see how the domain model changes without a corresponding change in the data layer).
And JDO is better placed to help this happen as it uses an object model to drive the persistence of the application - the data storage is mostly generated automatically from it.
S Rajesh Babu
Domain v's Object Model. Truth is that the 2 overlap - If you know what your doing you can build a model that is both intuitive (object model) and performant (relational model). Trick is to know what your doing.
If you want a good article on why EJB Entity beans won't survive the recession read:
You could use JDO behind a DAO if you don't want to tie your client to JDO.
If you don't want to tie your client to JDO, you don't need to hide the object model (which is developer written and not tied to JDO) behind DAO's.
You only need to abstract out the factory methods (that get and make persistent your normal java classes, querying, etc).
That way you could port the persitence related items to a separate framework if necessary.
Regarding isolating client code from JDO, Floyd said:
<floyd>You only need to abstract out the factory methods (that get and make persistent your normal java classes, querying, etc).</floyd>
Alternatively you could use the PersistenceManagerFactory and PersistenceManager interfaces as they are. You code direct to JDO. If you decide to change your JDO-compliant transparent persistence implementation to a different non-JDO transparent persistence implementation, you could code some concrete classes implementing the required interfaces to act as adapters to the new mechanism.
This saves you from having to write your own proprietary interfaces to describe the bahaviour of a persistence infrastructure....
Kind regards, Robin.
I am so glad to see this. Maybe this is a sign that JDO is going up in the political world at Sun?
was always a joke, and made people think twice on whether this is a technology Sun supports.
I hope this is a sign.
Maybe this is a sign that JDO is going up in the political world at Sun?
Either the java community rallies around *some* workable standard for O/R mapping, or Microsoft will take more territory in the enterprise information system market. Problem is, I don't think Sun realizes that, and I don't see either of the big players in the O/R mapping tool market taking the initiative and using the JCP process to get new standards going.
Currently for O/R mapping with Java (which is something that is needed by a huge majority of the java apps that businesses use) you have the choice of (1) locking into a proprietary system (shop bought or home grown) or (2) Entity EJBs with CMP. But both are bad options.
The disadvantages with (1) proprietary systems and vendor lock-in are obvious, even if the vendor is producing a good product.
But Sun *still* doesn't seem to have figured out that (2) Entity Beans with CMP, are a bad idea. Which is amazing: given the horrible hacks developers have to use just to try to get inheritance working for Entity Beans, I'm stunned that Sun still doesn't seem to be aware that conflating your component model and your domain object model is a mistake.
Perhaps Microsoft is right: perhaps the JCP process really can't supply the open standards that are needed. Certainly JDO's emphasis is on sexy new OO database technologies, not on the bread-and-butter tools that most real-world projects need. And I don't see either of the leading O/R mapping tool providers taking the initiative and setting up a new JSR, and I can't think of any economic reason why they would.
<Sean>Perhaps Microsoft is right: perhaps the JCP process really can't supply the open standards that are needed. Certainly JDO's emphasis is on sexy new OO database technologies, not on the bread-and-butter tools that most real-world projects need. And I don't see either of the leading O/R mapping tool providers taking the initiative and setting up a new JSR</Sean>
In my opinion JDO is not geared exclusively towards 'sexy new OO database technologies'. It supports f.i. a clean OO domain model by a appropriately object-oriented persistence layer API. This can be implemented using ODBMS's and RDBMS's. This O/R mapping aspect is hidden though from the perspective of the user, as I'd want it to be.
I don't know actually if the leading O/R mapping tool providers support JDO. Certainly vendors with less market share (f.i. ODBMS vendors) stepped in first in supporting JDO. But if JDO has gained sufficiently momentum I think they will support it.
So I don't see the need for a new JSR in this respect.
I must admit I'm a bit suspicious of opinions with a 'I used to be a Java adept but maybe Microsoft is right'-slant. Maybe unjustly so in this case.
I will be interesting to see how Microsoft fills the gap in its enterprise solution range with respect to persistency. Doug Purdy mentioned ObjectSpaces.
Wouldn't it be funny if they came up with a kind of JDO?
By the way I agree that Sun would be wise to position JDO as an alternative to entity beans. I can see that they don't want to cause unrest in the J2EE world. And maybe it's hard after the hard effort put into entity-beans 2.0 with CMR and all.
But the challenge by MS causes this unrest anyway. So...
groeten uit Nederland
"Perhaps Microsoft is right: perhaps the JCP process really can't supply the open standards that are needed."
As irritating as Sun's leadership can be sometimes, I still prefer an "industry standard" to a real standard. The problem with "industry standards", e.g. the x86 architecture, Java, etc... is that you are at the mercy of a single company. On the other hand, ISO and ANSI standards are also created by companies. Just look at SQL. C.J. Date wrote a whole book called "A Guide to the SQL Standard", which explains that the SQL standard is vague and therefore (say I) pretty much a failure. As you may guess, the standard is vague where it must accommodate two or more existing commercial products (e.g. Oracle and Sybase) which have two completely different features.
The JCP has the same problem as ISO and ANSI: it creates standards as compromises between software products. This is fine for creating adapters to proprietary technologies, but it can never really change things.
Contrast this process of negotiation among vendors to the open source development process, where the users are also the developers and designers, and choose features that make sense.
One possible to improve the JCP is to ask the developers what they need, as opposed to asking the vendors. Have developers discuss features in online discussion threads, and then somebody at Sun could consider all the opinions and come up with some compromise. This kind of process would have produced jdo from the start instead of entity beans.
I have no JDO experience at all but after reading a little about it I am curious. Can anybody help me with the folowing questions please?
How does JDO handle primary key generation? Does/cn the particular implementation you use autogenerate a pk AFTER you try and persist an object?
Or do you have to generate your own primary key (perhaps with the use of a 3rd party pk algorithm) and 'set' this into the applicable field in the object BEFORE you make the call to persist?
Any help would be appreciated and could greatly make the presentaion I have to give this afternoon a whole lot easier! Thanks, Vince.
JDO offers either automatic key generation (datastore identity) or application key generation (application identity). If you want the JDO implementation to handle key generation for you, you define your object model without any identity fields. The key generation happens sometime after you call makePersistent and before commit (deliberately not specified).
If you choose application identity, then you can use any number of techniques for key generation. In this case one or more of the persistent fields are key fields, and you set the key values before calling makePersistent.