Migrating from Jena1 to Jena 2

Jena 2 supports the Jena 1 API. However a number of changes have been made that will cause existing code not to run out of the box. The Jena team expect that there will be tools to help with the migration of Jena 1 code, but they don't exist yet, as we are not encouraging folks to migrate.

The changes are conceptually minor, mostly just renaming things into a more sensible pattern. Exceptions are reification and a bug fix on the I/O API.

What Must be changed:

package renaming

The old mesa.rdf part of the package names has been eliminated.

logging uses Commons logging

The old logging package in .util.Log has been removed. Jena now uses Commons logging and, optionally, log4j for its logging. Any users who used the old logging package should switch to log4j.

new model factory:

Models in Jena 1 were created using new on the model class. With Jena 2 there is factory for creating new models com.hp.hpl.jena.rdf.model.ModelFactory. Use that instead of new. If for some reason you cannot do that, the memory model class has moved to com.hp.hpl.jena.mem.

DAMLSelector has gone

DAMLSelector has been eliminated; SimpleSelector on a DAML (or OWL) model will do an almost equivalent job, because those models infer the necessary transitive triples.

I/O bug fix

Changes in the RDF/XML parser now mean that (the frequent) character encoding problems related to use of java.io.FileReader are reported. Changes in the RDF/XML output means that the not-so-very-portable character encoding used in a java.io.FileWriter is explicit in the XML document. See the IO mini HowTo for more explanation.

reification changes

Statements are no longer Resources. Instead Statements can be converted into Resources using the asResource() method. These new Resources are ReifiedStatement objects. See the API proposal document for the moment.

Statement.set

The Statement.set(X) methods have been removed. In its place we have the Statement.changeObject(X) methods. These methods update the model in the same way, but they do not alter the Statement object - they construct a new one and return it. This avoids certain technical difficulties which arose from having mutable Statement objects.

What Should be Changed

new SimpleSelector

SelectorImpl was the only case (other than creating models - see above) where applications had to use a specific implementation class rather than a class defined in the API. A new SimpleSelector class has been added into the API package. This is a clone of the old SelectorImpl class. The old class still exists in the com.hp.hpl.jena.rdf.model.impl package so existing code won't break with the right import, but moving to the new class is encouraged. The old one will eventually be deprecated.

*Impl classes

Some folks have used some of the implementation classes directly instead of using the factory methods provided in, e.g. Model. We are tidying up the javadoc so that the implementation classes are no longer so visible. Rather than renaming the import, it would be better to switch to using the factory methods. However, the *Impl classes still exist, and if you need a quick fix, many of them can be found in com.hp.hpl.jena.rdf.model.impl.

getProperty does not throw exceptions

Previously (right up to and including J2Beta1, in fact), the methods Resource::getProperty(Property) and Model::getProperty(Resource, Property) would throw an exception if no statement with the given resource and property were found in the model. In Jena2.0, if no statement is found, they will deliver null.

The original behaviour has been retained in the new methods Resource::getRequiredProperty(Property) and Model::getRequiredProperty(Resource, Property).

iterators now implement java.util.iterator

which means the .next() method returns an Object rather than a typed object. You need to either cast the return from the .next() method to the appropriate type or use the .nextType() (where Type is Resource, Literal, Ns, RDFNode or Statement depending on the iterator) to avoid casting.

Exceptions

The old RDFException is still available, but only to support legacy code. See the jena2-api-changes document for more details. Jena now throws unchecked exceptions, so various uses of try-catch to catch non-Runtime Jena Exceptions and convert them to runtime exceptions can be removed.

Dublin Core Vocabulary

For maximum backwards comapatibility change uses of "DC" to "DC_10".

The class "DC" will now track the latest Dublinc Core vocabulary. The classes DC_10 and DC_11 are the actual voabularies for v1.0 and v1.1 respectively.