You mean that both the attribute interface and the get/set version should be provided?
Yes, where an interface extends Attribute (such as JobInfo) it could define several utility get/set methods that encapsulate the semantics of that interface. These methods could simply store values using the Attribute methods. This solution is not especially pretty, there is no encapsulation of the underlying storage.
-5.5 Implementations could be provided for generic classes to prevent developers from needing to re-implementing, for example; Attribute, Context. Obviously implementation specific subclasses of these would have to be defined as 'abstract' classes. Rather I think that an interface only solution is simpler and more flexible in the long term, default implementations of generic classes could still be provided. See above: the spec talks about classes by now. Do you think that this limits flexibility overly much? In our opinion, the implementors of SAGA have the same flexibility as before, and the users of SAGA don't need it, really. What do you think? I am not clear about the interface/class distinction in SIDL.
In the Java world interfaces are more *fashionable* than class inheritance. There is little to be gained from abstract classes apart from tying developers to code defined by the language bindings. It is also harder to introduce a bug into a Java interface.
The purpose of the SAGA API is to define an interface. The implementation developers are not tied to an implementation of the utility classes, and the users should not care.
I am not sure about the implications either, but one thing which keeps popping up is that Java interfaces can't have constructors. However, the API specifies a number of constructors, so, in Java, that would defy the interface only approach - how do you handle that?
Java interfaces are the most flexible approach, especially since Java does not support multiple inheritance. When you look at the issue there are good reasons for interfaces not to support constructors. It is a pain but just something that has to be lived with. We must expect developers to honour the documented constructors for an interface. Another solution (which I like) would be to extend the concept of factory classes (already used within the SAGA API). The constructors could then be defined by the methods of the factory class(es). Factories would also assist the dynamic loading of SAGA implementations at runtime. Graeme