tags: java odf odfdom xml

A new version of ODFDOM - the OpenDocument Java API - has been released!
ODFDOM is an Apache 2 licensed Java library to easily create, access and manipulate ODF documents.

If you never have heard of ODFDOM, you might want to get a quick overview first.

With this release we made an enormous step forward!
It took us several months of continuous refactoring until we finally agreed on shipping this new release. 'We' are in this case Benson Margulies, David Eisenberg and a group of IBM and Sun developers.

The 0.7 is more than worth to be called a release, embracing several stunning new features, the best listed below:

ODF 1.2 support

ODF usability

To ease the DOM handling, every element now has methods to create their element children, requiring mandatory information as parameters. With this users no longer have to look into the RelaxNG schema to verify if an element is allowed as a child.
Furthermore there are methods to access all possible attributes of the element, as well as enumerations for their possible values.
Aside of elements and attributes there are now as well classes for all data types listed in ODF 1.2 (mostly W3C schema types, which now bear validate and helper functions).

Finally, the convenient layer of ODFDOM shows examples how easy a final API might look like.
For instance it is a simple three liner to

1. create a new ODF document,
2. add text and
   
3. save the new document.

OdfTextDocument odt = OdfTextDocument.newTextDocument();
odt.addText("My important text");
odt.save("MyExample.odt");

Documentation

David Eisenberg has contributed new tutorials.
Our JavaDoc has been improved. Now every single ODFDOM element/attribute class links to an XHTML version of the spec, where the functionality of the XML node is being described in detail. This spec is bundled with the JavaDoc (soon the spec will be separated in smaller pieces to speed up loading times).

Build environment

Last but not least, with the support by Benson Margulies, we were able to switch our build environment from ANT to Maven. By using Maven we made our dependencies declarative. We no longer add dependent JARs to our sources (e.g. the parser XercesImpl.jar), but are able to download them via Maven on demand. Following this idea of modularization, we were able to simplify the source structure of ODFDOM by moving our code-generation to an own new project called relaxng2template.

Still interesting challenges lie in front of us and we hope with this release we are able to arouse interests at like-minded developers to join our efforts!

I hope you all enjoy the new release!
Svante

tags: api java odf odfdom opendocument

I just recently started a discussion on jdk@tools.openoffice.org regarding the OOo Java baseline. Background was the open sourcing of Java to the OpenJDK project, and OpenJDK becoming fully functional, please see my other posting for some details.

There are two points I would like to discuss respectively to announce here, in case nobody objects. Both points are based on an overview listing the OOo platforms and the used Javas respectively the availability of OpenJDK, please see here for the details.

1) While discussing the OpenJDK switch with Svante Schubert, we observed two (pressing) issues in OOos current Java libraries. The first issue is, that some libraries are checked in in binary form, while the second is, that some libraries are functional redundant. Please have a look at Svantes posting for the details. Plan is to fix both issues before releasing OOo 3.0. Unfortunately that means, that we need to raise the Java baseline from 1.3.1 (see here for the old but still current OOo Java policy) to 1.5.

2) Later on, after the availability of OpenJDK (or a compatible version as for Mac OS X), I suggest to switch to OpenJDK as the baseline for OOo, always using the latest OpenJDK available on all of OOos platforms. That would eliminate the need to come together every once a while and to rediscuss Java baselines ... Generically I would express the OpenJDK baseline like this: "Every (Java) developer can expect that an OpenJDK (of a particular release) or better (a Sun, IBM or whatever Java with a higher version number) can be used to build and run OOo. No Java developer shall use any non-standard API and shall ensure that his/her code runs with OpenJDK or better."

There are still some unknowns in the Java platform listing, I did mail the listed owners of these platforms (as listed on http://porting.openoffice.org). Unfortunately some of the mail addresses are not valid any more. So, if you think that you are stakeholder and that the above proposals are not suitable for you, please let me know urgently.

Regards

Kay

tags: baseline java openjdk openoffice openoffice.org

tags: extensions java openoffice.org

The upcoming cleanup of OOo's Java class path turned up an interesting issue in OOo's database module: Each database document uses some Java code (sdbc_hsqldb.jar) that in turn uses a native library (hsqldb2). Until now, sdbc_hsqldb.jar was on OOo's global Java class path, was thus loaded once by the global application class loader, and thus made just one System.load call to load the native hsqldb2 library, no matter how many different database documents were open in a single OOo session.

Now, sdbc_hsqldb.jar is no longer on OOo's global Java class path, but rather each database document sets up a dedicated URLClassLoader to load the jar. That means that each database document loads a different instance of the jar's classes. And that means that each instance calls System.load to load hsqldb2. When System.load is asked by two different class loaders to load the same library twice, it throws an UnsatisfiedLinkError the second time (this is not obvious from the documentation, but you can verify it by reading the code). This is certainly in there for a reason (at least some OSs probably just cannot load the same native library more than once into a single process, and sharing a single native library instance across class loaders is presumably a security issue). However, it is a rather unpleasant interference: OOo's database documents stopped to work.

This asks for caching: Instead of one set of Java classes per document, reuse already loaded classes across documents. It turned out that doing this in a reasonable way via JNI is a rather nontrivial endeavor. It left me with an issue full of open questions (a cry for help, of sorts).

tags: java