Page 1
"JPOX JDO 1.2" ?
JPOX implements JDO1/JDO2 yes, but it also implements JPA1 ... and we have
never used the name "JPOX JDO" in the last year. Version 1.2 is not out yet.
You mean 1.1.6? (most recent production release) ? or 1.2.0-beta-1 ?

Page 2
JPOX has "log4j" as a dependency. This is optional and if using JDK1.4+ you
would have had logging via java.util.logging otherwise. You have "c3p0" for
Hibernate (and so are using connection pooling) yet you dont for JPOX (and so
arent for JPOX). This will significantly impact any performance!

Page 4
I've seen many benchmarks showing JPOX way ahead of Hibernate on updates
(never seen anything to the contrary). On INSERTs I've occasionally seen
Hibernate faster (since it has batching enabled, whereas you have to wait for
a later version of JPOX for that). As always there are reasons for
differences between Hibernate and JPOX when they have the same functionality
available ... JPOX uses the byte-code enhancement process and avoids
reflection and so is faster in many areas. I don't see this mentioned and
would have been good to see it as the reason why bytecode enhancement is
used .

What you could have done in the performance section is try to address what you
did to get those performance results. JPOX and Hibernate have much
configuration that can be done and these can completely change the
performance (and I mean completely). Again, the comment about connection
pooling (above).


Page 6
"JDO takes a different approach. It allows lazy loading, but does not load
anything into the lazily loaded field like addresses. In fact, if you access
the property directly, you will see that the lazy loaded field would contain
null. This can cause some issues if you don’t properly access the data with
getters and setters:"

Access the data from where ? another class that you didn't bother marking as
"PersistenceAware" ? If you mark any class that accesses fields directly as
"PersistenceAware" then you have NO issue.

probably because of the lack of connection pooling