The Java Binding, version 1.1b

Episode IV: A New Hope

For reasons discussed elsewhere, it became apparent as I was trying to build an implementation of binding version 1.1a that the whole approach of doing it by implementing interfaces was flawed. This is disappointing, because it just feels like The Right Thing, but there's no point in whining about it more than I already have :-)

Accodingly, version 1.1b of the Java Binding is a complete, ground-up reworking, essentially throwing away 1.1a and starting again.

The approach this time is to build an implementation as I go along. That way I have proof of concept. I already had the API sketched out when I started (the remnants of 1.1a, transformed from interfaces into classes), and I've been changing it as I go along.

The changes from the initial ``transformed 1.1a'' state were largely to rescue the Java binding from some silly design decisions that were inherited from the C++ binding, where they made sense. For example, in the C++ binding, the Connection class has no search() method: searching is done by the ResultSet constructor. The reason why this makes sense in C++ do not apply in Java, so I've reinstated Connection.search().

The Binding Specification

My in-progress implementation is documented using standard Java ``doc comments''. The binding's API specification is the output of javadoc run across those files.

Please don't be put off by the uk.org.miketaylor.zoom package name. That's just because javadoc happened to run on my implementation. You can, of course, build your own Java Binding implementation in the package of your choice. Of course, it should be trivial to swap any given ZOOM/Java application between two or more different implementations. All that's necessary is to change the

import uk.org.miketaylor.zoom.*;

import the.vendor.of.your.choice.zoom.*;

Issues

I'm sure there are plenty of issues with this binding specification that I have not yet spotted, but here are a few areas that I am particularly keen to sort out:

• What are we going to with the Global class? At best, the name is surely wrong; at worst, the whole concept is misguided - but we do need a holding space for genuinely non-instance methods (what we used to call ``functions'' in the old days) like code2msg()

• What are we going to do about records? All the polymorphism issues that we wrestled with in the C++ binding seem just as real here.

• It is always reasonable to represent Bib-1 diagnostics as exceptions? If not, is it reasonable to pass Bib1Exception objects around like ordinary data, rather than throwing them? Do we need a hierarchy of different exception classes, or is one with an errcode() method sufficient?

Comments, please, to the ZOOM mailing list in general; but you can send them straight to me if they reveal a really embarrassing mistake on my part :-)