Subject: Java GSSAPI: Interfaces vs. Concrete classes

From: Joe Salowey <[email-masked]>
Date: Tue, 2 Nov 1999 16:13:08 -0800

After some discussion, Mayank and I think we have come up with a workable
solution for interfaces vs. concrete classes.

The sticking point was around the GSSManager class.  A concrete GSSManager
class  allows each implementer of the Java VM (ie., Sun, IBM, ,HP, etc) to
create their own  GSSManager class with a standardized well-known name and
method signatures.  This allows multiple implementations of GSSAPI, but only
one is  present on a particular VM.  This may work well for applications,
but it complicates life  for applets.  A particular VM's GSS implementation
may not have the mechanism an applet requires.  Therefore we need to allow
the applet to provide its own implementation.   Since java has a global
namespace there can only be one GSSManager class. In order for  things to
work the applet GSS mechanism implementer would have to subclass GSSManager
and  override all the methods.  This is both confusing (if the mechanism
writer tries to  replace GSSManager things may not work) and difficult since
there is no implementation of  GSSManager available yet. 

The solution is to make GSSManager abstract.  This way it is clear that the
mechanism  developer must subclass it to have a working implementation and
it is easy to provide a  sample abstract GSSManager.  GSSManager also
provides a static getInstance method which  will obtain the "default"
platform implementation which can be queried for the  appropriate mechanism
and provider.  If the appropriate mechanism is not found than a specific
subclass of GSSManager can be instantiated directly.  

The classes that are already interfaces (GSSContext, GSSCredential, GSSName)
remain  interfaces.  The other concrete classes (OID, ChannelBinding,
MessageProp, GSSException)  are sufficiently generic, encapsulated and
well-defined that they are interchangeable from  implementation to
implementation (It would be great if we had reference implementations of
these). 

Joe
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Michael Smith <[email-masked]>
Date: Tue, 02 Nov 1999 20:46:27 -0500

>solution for interfaces vs. concrete classes.
[....]
>it is easy to provide a  sample abstract GSSManager.  

Frankly, I'm still a little baffled about why folks think it's 
important to have GSSManager be either concrete or semi-solid
(i.e. abstract), as opposed to being an interface. 

As has been noted before, if Sun wants to ship a default GSS 
implementation, with or without a static method, there's no reason 
why it shouldn't do so, even if org.ietf.GSSmanager is only an 
interface. 

In any case, the application programmer must 1) import something
(Sun's standard implementation, or somebody else's) 
and 2) get an instance of something. So I see no advantage 
whatsoever to making GSSmanager anything but an interface. Against 
this must be weighed the loss of flexibility if we make it 
a class, either abstract or otherwise: Java provides no multiple
inheritance of classes, but it does for interfaces.