# Re: Problems with java.security

Roland Schemers (Roland.Schemers@Eng)
Tue, 16 Jun 1998 14:54:46 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Uday Shah: "SSL in JCE 1.2"
- Previous message: Sean Rohead: "Problems with java.security"
- Maybe in reply to: Sean Rohead: "Problems with java.security"

    Message-Id: <199806162154.OAA13881@crypto.eng.sun.com>

    Date: Tue, 16 Jun 1998 14:54:46 -0700 (PDT)

    From: Roland Schemers <Roland.Schemers@Eng>

    Subject: Re: Problems with java.security

    To: java-security@web2.javasoft.com, sean@itsnet.com

It would be a major incompatible change to change something from
an abstract class to an interface. In general, Identity/IdentityScope
are deprecated in JDK1.2. We are working on an extension which will be
based on the Principal interface instead. Identity has too much baggage
to try and use it.

roland

> 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
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
>
> 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.
>

- Next message: Uday Shah: "SSL in JCE 1.2"
- Previous message: Sean Rohead: "Problems with java.security"
- Maybe in reply to: Sean Rohead: "Problems with java.security"