From: "Sean Rohead" <sean@itsnet.com>
To: <java-security@web2.javasoft.com>
Subject: Problems with java.security
Date: Tue, 16 Jun 1998 15:44:15 -0600
I would like to comment on what I see as troublesome deficiencies in the
java.security API. I have written subclasses of the abstract classes
java.security.Identity and java.security.IdentityScope. I have run into a
problem that stems from the unfortunate decision of making these classes
abstract instead of interfaces. The fact that they are abstract classes
makes them extremely non-extensible. Allow me to illustrate:
Let say I create a class called AcmeIdentity which extends
java.security.Identity. I would like to add additional functionality and so
I add some new methods to the class. Now, when I implement
AcmeIdentityScope, I am immediately faced with the impossibility of
inheriting the new functionality in AcmeIdentity because I must extend
java.security.IdentityScope. If it were an interface, I would not have this
problem. So, I bite the bullet and duplicate the code in AcmeIdentityScope
rather than inherit it. However, my problems only get worse. At some
point, when I decide to use the new methods, I will need to have a statement
similar to the following:
if(identity instanceof AcmeIdentity)
{
((AcmeIdentity)identity).newMethod(...);
}
However, this code fails miserably when the identity reference actually
refers to an AcmeIdentityScope, since AcmeIdentityScope does not (in fact,
CAN NOT) extend AcmeIdentity. So I have to add another if statement which
checks for AcmeIdentityScope. This could not be more error prone!!!
All of these problems stem from making IdentityScope an abstract class. I
presume the purpose of this is to allow the java.security.IdentityScope to
have the "private static IdentityScope scope" data member which is necessary
to implement the getSystemScope() method. As a suggestion, this could be
moved to java.security.Security, which is a final class and therefore is
immune to the problems described above. Besides, java.security.Security
already has the "system.scope" property, so it's really not an unnatural
place for this.
Perhaps it's too late to fix this problem, but if there is any way this can
be changed in JDK 1.2, it would be a great improvement. Perhaps I have
overlooked something, and there are technical barriers to such a change. I
would be grateful to hear your thoughts...
Sean Rohead
Corel, Inc.