What do you think about JDO?

[Bernd]

Hi guys,

I am programming two java tools that will use a mysql database
in order to - you will be quite surprised - store and retrieve
user data.

I am thinking about learning JDO and using it for these tasks.
So, some opinions on JDO?
Are there disadvantages that I should know about?
Should I better stick to good old JDBC and SQL?

I am not so much interested in technical/implementation issues
(well let's say less interested), but more in design and concept.
Can I develope my java programs more efficiently /elegantly with JD0?



Greetings
Bernd

P.S.
If you don't know what JDO is, but are interested, have a look
at www.jdocentral.com for example.

There is also a free implementation at www.jcredo.com,
bit I don't know whether it's good or not.

 

[Chris Smith]

I am programming two java tools that will use a mysql database
in order to - you will be quite surprised - store and retrieve
user data.


I am thinking about learning JDO and using it for these tasks.
So, some opinions on JDO?
Are there disadvantages that I should know about?
Should I better stick to good old JDBC and SQL?

My opinion is that JDO, like much of what comes out of the JCP these
days, is needlessly bloated and complex because it tries to be too
general and fails to get into the details of solving real and specific
problems. While it it a decent concept, there are better
implementations of O/R mapping around, both commercial (TopLink) and
free (Hibernate).

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Bernd]

My opinion is that JDO, like much of what comes out of the JCP these
days, is needlessly bloated and complex because it tries to be too
general and fails to get into the details of solving real and specific
problems. While it it a decent concept, there are better
implementations of O/R mapping around, both commercial (TopLink) and
free (Hibernate).

Dear Chris Smith,

I haven't used Toplink or Hibernate before, but I will have a look
at Hibernate. May I ask you for a short, educative example or
some specific reasons, why you consider Hibernate better than
JDO?

Bernd

 

[Gerbrand van Dieijen]

Hi guys,

I am programming two java tools that will use a mysql database
in order to - you will be quite surprised - store and retrieve
user data.

I am thinking about learning JDO and using it for these tasks.
So, some opinions on JDO?

Hello, I use it currently and I think it's really great.
Lot's of things I used to do by hand, are now done completely
automatic.

Are there disadvantages that I should know about?
Should I better stick to good old JDBC and SQL?

Definately not. Only in some cases SQL would be preferrable
for example when you need Aggregate functions (hopefully this
will be added to JDO soon), or when your JDO implementation
generates inefficient query's for some case (although you can
always switch and there are implementations that don't use SQL
at all).

I am not so much interested in technical/implementation issues
(well let's say less interested), but more in design and concept.
Can I develope my java programs more efficiently /elegantly with JD0?

I can't speak for other persistency frameworks, but I'm certain it
is much more efficient and elegant then using JDBC and writing you're
own persistency code.
The only similar solution I know something of is J2EE Enterprise beans.
At least for the part both technologies overlap, JDO is more simple to
use and has the advantage that it won't need any J2EE server to
run.

Greetings

 

[Chris Smith]

I haven't used Toplink or Hibernate before, but I will have a look
at Hibernate. May I ask you for a short, educative example or
some specific reasons, why you consider Hibernate better than
JDO?

There are a good number of reasons that I consider Hibernate better than
JDO. Here are a few.

1. Most importantly, I think Hibernate is able to provide a *much* more
transparent mapping, which allows you to more easily write code that
*uses* the data without needing to worry about the details of your
persistence layer. You can even serialize data objects directly to
machines that don't have access to the database (a task that previously
required writing yet another duplicate set of data objects!).

2. The core approach to the problem is much nicer in Hibernate (where
transparency is achieved through runtime code generation) as opposed to
JDO (where the same is typically achieved through an extra build step
that modifies your compiled bytecode). That makes the project less
dependent on a complex build process.

3. Hibernate provides for a far more flexible mapping, allowing you to
avoid fencing in your database design because of the O/R technology you
plan on using.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Adam Jenkins]

Dear Chris Smith,

I haven't used Toplink or Hibernate before, but I will have a look
at Hibernate. May I ask you for a short, educative example or
some specific reasons, why you consider Hibernate better than
JDO?

One problem I saw with JDO compared to Hibernate last time I checked, is
that JDO has no standard way to map objects to an existing database
schema. It insists on creating its own schema. If you're writing a new
application and all access to the database will be through JDO, then
this isn't a problem. However in practice it's quite common to need to
write a Java interface for accessing an existing database, which may
also be accessed in other ways. With Hibernate you can specify exactly
how objects map to the database structure, but JDO has no way to handle
this common situation.

If this is no longer true please correct me.

Adam

 

[Dale King]

Dear Chris Smith,

I haven't used Toplink or Hibernate before, but I will have a look
at Hibernate. May I ask you for a short, educative example or
some specific reasons, why you consider Hibernate better than
JDO?

As a coincidence, our local Java User Group is having a presentation on JDO
tonight by Patrick Linskey, the author of Bitter EJB. I can only attend a
little bit of it, but wondered if anyone had any questions/comments on JDO
to pass along?

 

[Bernd]

Dear Chris Smith,

thanks for your opinion on Hibernate. I think you were quite right.
I have just finished reading the documentation and some tutorials
and started using it for one of my projects.

Regards

Bernd

 

[Gerbrand van Dieijen]

One problem I saw with JDO compared to Hibernate last time I checked, is
that JDO has no standard way to map objects to an existing database
schema. It insists on creating its own schema. If you're writing a new
application and all access to the database will be through JDO, then
this isn't a problem. However in practice it's quite common to need to
write a Java interface for accessing an existing database, which may
also be accessed in other ways. With Hibernate you can specify exactly
how objects map to the database structure, but JDO has no way to handle
this common situation.

No, this this depends on the implementation of JDO.
Most commercial implementations (like JDOGenie, the product I use) allow
mapping to existing tables as well.

 

[Adam Jenkins]

.... SNIP ...


No, this this depends on the implementation of JDO.
Most commercial implementations (like JDOGenie, the product I use) allow
mapping to existing tables as well.

That's why I said no *standard* way. Since it's such an obvious
omission, most JDO vendors have implemented some non-standard way to do
it, but then you're locked into that vendor's JDO implementation.

 

[Gerbrand van Dieijen]

That's why I said no *standard* way. Since it's such an obvious
omission, most JDO vendors have implemented some non-standard way to do
it, but then you're locked into that vendor's JDO implementation.

JDO is not specificially meant for SQL-databases, so that's why it is not
part of the standard.. Also there are different methods to map
Java-object to relation SQL. Now there is no standard, vendors can use
there own most efficient ways of doing it, rather than using a suboptimal
standard.

Besides, because JDO is a standard, it should be quite easy to create a
tool to transfer are you're data from one JDO storage to another.

Not everything is or should be standard!
To mention something, even if you would make a standard
JDO->SQL standard, the standard to store the data on disk by the
SQL-database is non-standard, so you can't just copy your files from one
database to another. Besides, filesystems aren't standard too, so you
can't to byte-to-byte copy to transfer to another filesystem/os (we could
go on for a while ;-) ).

 

[Adam Jenkins]

JDO is not specificially meant for SQL-databases, so that's why it is not
part of the standard.. Also there are different methods to map
Java-object to relation SQL. Now there is no standard, vendors can use
there own most efficient ways of doing it, rather than using a suboptimal
standard.

JDO may not be specifically for SQL databases, but I'd bet that that's
where it will in fact by used in the vast majority of cases. I don't
believe the lack of a JDO-SQL mapping is an intentional omission, it's
just a hole in the standard. The case we're talking about here is where
there's already an existing schema, and we'd like to use JDO to access
it from Java. There's only so much optimizing an implementation can do
in this case, since it can't change the schema. I don't see why
standardizing the interface for mapping to existing SQL schemas would
significantly limit what optimizations a vendor can do, if the interface
is well designed. The fact that every vendor is doing it is good
evidence that it's a common need, and should be standardized.

I'm not the only one who thinks the lack of a standard JDO-SQL mapping
is unfortunate. See this link:
http://www.ogilviepartners.com/JdoFaq.html
Look at the question "Can JDO map to an existing Relational Table
Structure?"

And this link:
http://www.jdocentral.com/JDO_Commentary_AbeWhite_1.html

Another, with an interesting perspective on why this might have been
left out of the JDO spec:
http://www.oreillynet.com/cs/user/view/cs_msg/12445

Besides, because JDO is a standard, it should be quite easy to create a
tool to transfer are you're data from one JDO storage to another.

You can't seriously think that's a solution; maintain copies of all the
company's databases just so they can be accessed using JDO?

Not everything is or should be standard!
To mention something, even if you would make a standard
JDO->SQL standard, the standard to store the data on disk by the
SQL-database is non-standard, so you can't just copy your files from one
database to another. Besides, filesystems aren't standard too, so you
can't to byte-to-byte copy to transfer to another filesystem/os (we could
go on for a while ;-) ).

That's why there's a standard filesystem API for any given OS, so you
*can* transparently copy files from one type of filesystem to another.
The fact that there's a standard API makes the actual on-disk format
irrelevant to the client code. JDO aims to do the same thing for
databases, but the lack of a standard JDO-SQL mapping interface means
you just replace DBMS dependce with JDO-vendor dependance. Hopefully
Sun will fix this hole, but until then I'll stick with Hibernate; at
least it's open source.

 

[Gerbrand van Dieijen]

Another, with an interesting perspective on why this might have been
left out of the JDO spec:
http://www.oreillynet.com/cs/user/view/cs_msg/12445

That was pretty interesting to read. They (and the other links) have a
point there, although there are is an open source JDO implementation and a
free (but commercial) implementation of JDO too now. TJDO is open source,
see http://www.sf.net and there's JCredo which was and I believe still is
free, even for commercial use (but without support then).

You can't seriously think that's a solution; maintain copies of all the
company's databases just so they can be accessed using JDO?

Of course not . I wanted to point out, you won't be locked into one JDO
implentation, even if the SQL mapping is different. With some effort
(should the JDO vendor changes is disclaimer or goes bankrupt for
example), it is very well possible to switch to another JDO
implementation, without having to rewrite or change code.

That's why there's a standard filesystem API for any given OS, so you
*can* transparently copy files from one type of filesystem to another.
The fact that there's a standard API makes the actual on-disk format
irrelevant to the client code. JDO aims to do the same thing for
databases, but the lack of a standard JDO-SQL mapping interface means
you just replace DBMS dependce with JDO-vendor dependance. Hopefully
Sun will fix this hole, but until then I'll stick with Hibernate; at
least it's open source.

The filesystem -> diskmapping is non-standard! ext3 maps differently to a
disk then NTFS, which maps differently to FAT32, etc.

 

[Adam Jenkins]

The filesystem -> diskmapping is non-standard! ext3 maps differently to a
disk then NTFS, which maps differently to FAT32, etc.

I still don't see how this is relevant to this discussion, since the
whole point of the driver is to hide the implementation. I can open and
save a file with emacs, whether the file is on a NFS filesystem or ext3
filesystem. Emacs doesn't need special NFS or ext3 support, it just
needs to use the native filesystem API for whatever OS it's running on.

Maybe what you mean is that not all filesystems provide the same
functionality? For example, FAT32 has a hidden attribute for files but
ext3 doesn't, and ext3 has an execute attribute for files but FAT32
doesn't. An equivalent for databases is that the JDBC API has BLOB
support, but not all databases actually support BLOBs. You can get
around that by:

1. making your application only use the subset of functionality common
to all implementations, for example just don't use BLOBs.

2. Another way is to can write your abstraction for the features not
supported by every implementation. For example, write your own BLOB
abstraction on top of JDBC that delegates to actual BLOBs for RDBMSs
that support them, and implements them some other way the rest of the
time.

3. Finally, you can just assume the existence of whatever features you
think are necessary for your app, and say your app will break if they're
not present. For example, say your app will break if the RDBMS doesn't
support BLOBs.

I think this is really what the discussion here was about. The
middleware proponents support something like the first two suggestions,
whereas a few people think that the only way to get decent performance
is the third option, and that the first two inevitably compromise too
much peformance and robustness in order to be portable.


Adam

 

[Gerbrand van Dieijen]

I still don't see how this is relevant to this discussion, since the
whole point of the driver is to hide the implementation. I can open and
save a file with emacs, whether the file is on a NFS filesystem or ext3
filesystem. Emacs doesn't need special NFS or ext3 support, it just
needs to use the native filesystem API for whatever OS it's running on.

That's what I meant, for using JDO you don't need the underlying SQL
implementation (if any) nor how it works, I said it as an example.

 

[Chris Smith]

That's what I meant, for using JDO you don't need the underlying SQL
implementation (if any) nor how it works, I said it as an example.

There's an important difference between filesystems and databases,
though. Filesystems can reasonably assume that they will be the only
piece of software accessing a disk. Applications can't assume they will
be the only thing accessing data. The data may predate the application,
and/or may live well past the application's death.

Because of that, applications often are required to conform to existing
representations of data. Some aspects that fit in as the implementation
details of a filesystem are actually analogous to a part of the
interface of a JDO implementation. That requires flexibility from the
JDO implementation that's not required of a filesystem.

In that sense, JDO doesn't completely insulate you from needing to know
that the database is relational and has a certain schema; that's often
part of the requirements for the application, and no technology magic is
going to make it go away. The solution has to be JDO implementations
that map to pre-existing database schema. Unfortunately, I've seen few
that provide substantial flexibility in letting you do that -- in fact,
the whole "transparent persistence" paradigm of JDO seems to discourage
it.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation