This one is really painful. An interface may not contain constructors. (It was hard to get Jikes to tell me this, by the way: it diagnoses interface constructors with a rather obscure syntax error, ``Identifier expected after this token''.)
Why is it this way? Pure short-sightedness, I guess. The reasoning would have been that since you can't intantiate an interface, you don't need to specify a constructor for it. Well, duh! The same reasoning applies to every other method prototyped in an interface! You don't put methods in interfaces because you want to invoke them; you put them there so that classes which implement them know what they have to provide. This is just as valid and relevant for constructors as for any other method.
I notice, by the way, that Java's own class library runs into precisely the same problem. O'Reilly's Java in a Nutshell, 3rd edition says in its description of the standard java.util.Collection interface (pp508-509):
An interface cannot specify constructors, but it is conventional that all implementation of Collection provide at least two standard constructors: one that takes no arguments and creates an empty collection, and a copy constructor that accepts a Collection object that specifies the initial contents of the new Collection.To quote Calvin (of and Hobbes fame), ``What a stupid world''. (In another strip, he comments ``It's either mean or it's arbitrary, and either way I've got the heebie-jeebies.'' How apposite.)
For presumably the same reason, it appears that even if we promote (say) Connection from being an interface to to an abstract class, with a constructor to be overridden, then we can't extend it with a class that defines a new constructor: jikes diagnoses this, rather unhelpfully, as ``No match was found for constructor "Connection()".''
Anyway. That's the reason that all the interfaces in the Java binding of the ZOOM API have their constructors commented out. When you write an implementation, you're supposed to include appropriate constructors.