News: JDO Maintenance Release: JDO 1.0.1
The JCP announced a maintenance release for JSR-12, JDO 1.0.1. This release (Final Release 2) has a few tweaks here and there, but the major item is persistence-capable classes can now be compiled by JDK 1.4. There are other minor changes and clarifications, such as the support for group read of objects and PersistenceManagerFactory.close().
- Posted by: Dion Almaer
- Posted on: September 17 2003 15:54 EDT
Several errata and clarifications have been made to the specification, the reference implementation, and technology compatibility kit, and this release includes them all, bar the TCK 1.0.1, which should be put up soon.
Go to the JDO 1.0.1 Maintenance Release
Go directly to the JDO 1.0.1 Change Log
Also, on a side note: Sun is running a survey to gauge the interest of J2EE developers in JDO. If you feel that Sun should take JDO a little more seriously let them know!
Go take the JDO survey!
Update: The message below is from the JDO spec lead Craig Russell, explaining the 1.0.1 Maintenance Release
In the year and a half since release of JDO 1.0, the community has endorsed the fundamental soundness of the specification by building an active community of over 8000 members on JDOCentral and implementing some 20 products that adhere to the specification.
During that time, minor impovements have been made to the specification to bring JDO up to the latest level of JDK and improve the ability of users to gracefully clean up resources.
The biggest user-visible change in JDO 1.0.1 is the support of JDK 1.4 for persistence-capable classes. The enhancer now supports classes compiled using JDK 1.4, so class developers can now use the JDK 1.4 assert keyword and use these classes with JDO.
Another big change in the enhancer is that you no longer have to tell the enhancer where to find metadata files. It finds them all by itself. But in order to do so, the command line interface to the enhancer has been, well, enhanced. A new command line option -s has been added to give the enhancer the location of the root of the class directory. The name of the metadata files is the same for single-class metadata but is changed for metadata containing multiple classes. To better fit into application servers and web servers, the metadata is first searched in the root directory under the name package.jdo. If not found, META-INF/package.jdo and WEB-INF/package.jdo are tried. Then, the file package.jdo is looked for in all packages starting from the root of the class directory. Finally, <classname>.jdo is looked for.
The specification was clarified for application identity key handling. Portable key field types are restricted to Number classes, Date, String, and primitives, and key field values must not be null.
Second Class Objects of non-persistence-capable types now have standard behavior. They must be treated as per the composition model, not aggregation model. Therefore, when the containing instance is deleted from the datastore, the SCO instances must also be deleted automatically.
The property javax.jdo.option.ConnectionDriverName was added to the standard set of properties managed by PersistenceManagerFactory and JDOHelper.
Two new methods were added to PersistenceManager to efficiently load fields for a group of objects: retrieveAll (Collection, boolean) and retrieveAll (Object, boolean).
To help users clean up resources, a new PersistenceManagerFactory method close() was added. This method allows the factory to close connection factories, close files, and clean up PersistenceManagers that have no open transactions. A security permission must be granted in order to close a factory.
The behavior of failed optimistic transactions is now standardized. If a failure occurs during commit, then the transaction is rolled back and the list of objects that caused the transaction to fail are contained in the exception. This standard treatment allows users to restore the application cache, and reload failed instances in order to replay the transaction.
The handling of queries in which the candidate collection is not specified has been standardized. The candidate collection is the extent of instances of the candidate class with subclasses true. This allows portable behavior of restored serialized Query instances.
A new exception was added to allow reporting an instance that cannot be found in the datastore.
- Woo Hoo! by Michael Niessner on September 17 2003 22:01 EDT
- nice to see some progress from JDO by Michael Mattox on September 18 2003 02:34 EDT
- JDO Maintenance Release: by Miroslav Nachev on September 18 2003 05:16 EDT
- Book or Tutorial? by Hans Schw?bli on September 19 2003 12:59 EDT
I am very happy!
It's nice to see some progress. I love JDO but one concern I have is that it's moving too slow to remain competitive with Hibernate. I don't see any reason for JDO to move so slow, other than the possibility that it can compete with EJB which SUN doesn't want. Many people are moving from CMP to lightweight ORM and if SUN doesn't take advantage of this, perhaps at the demise of CMP, then Hibernate will.
We try 3 JDO implementations (Sun, Castor and Apache Db). My opinion is that Apache Db is the best. Also the possibility from one XML file (Schema) to generate and to build all necessary files (Java Code, JDO descriptions, Database creation, Data population, etc.) is very useful.
Some interesting idea is Sun look at Apache Db and then to produce next release of specification.
Other interesting future when you have some virtual methods (transactional, transient field) to specify just GET method in the XML file. Also this Java code to inserted which in practise is (Java Stored Procedure).
I think that JDO is the future. The combination of JDO, EJB and JDBC is good working model.
Why JBoss doesn't support Apache Db?
Coincidentally I looked at a couple of opensource implementations last week
I never heard of of apache dbI think you mean apache OJB, which is a very incomplete implementation and isn't quite usable right now
castor JDO , isn't a sun JDO implementation, it's just confusingly also called jdo
Triactive JDO is another implementation, but it's versioning scheme boggles the mind, they are almost at 2.0 and they still don't fully support the spec, and amongst other things they have no support for optimistic transactions, and only support the HashSet collection, type (yes I know this is the bare minimum required), doesn't have a jca connector and doesn't support application identity
Speedo JDO seems the most full featured opensource implementation right now, it supports a wide array of collection types, comes with a jca connector (though admitably I haven't got it to work yet) it does support optimistic transactions, what it doesn't support is inheritance, nor incremental compiling since the bytecode enhancer has problems with code that has already been enhanced
it's authors say it's stable but then they release a new version and this is among the release notes
- Rollback tested !
they also dont have a very active community, the mailing list has 16 subscribers last I checked.
JBossDO I don't know too much about, but as generally is the case with JBoss they try to lock you in to their platform, you can't use it outside of JBoss, and that was basicly all I needed to know
Xorm I haven't had the time to look at
We try 3 JDO implementations (Sun, Castor and Apache Db).
You should have a look at Hemtech's version. It outclasses all of the above.
Of course, it's not free, but then neither is Sun's (AFAIK).
I think Hibernate is a serious thorn in the side. It is obviously an excellent, working, persistence engine that outclasses many commercial JDO implementations. As a result, people are torn between the free Hibernate that doesn't do JDO, and the lesser ones that do. There is no common tooling amongst the JDO vendors, so in theory the only thing standing in your way is "does it do the specification". My company used neither for a while due to that indecision, and finally settled on Hibernate.
The best way forward for JDO IMO, is for there to be an interim specification that doesn't add any new features, and lifts those restrictions that will enable Gavin to make Hibernate JDO compliant.
Can someone recommend me a good tutorial or book about JDO?
Our company uses a ERP framework which is coupled with CMP. I would like to write such a framwork too one day, but one with switchable persistence technology (CMP, JDO or an OR-Mapper).
The best book by far I think is the David Jordan and Craig Russell one "Java Data Objects". For starters, you can also use Robin Roos' book, which I think is freely available if you register somewhere.