JDK-4193604 : Interfaces should be able to support an implementation API.
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.1.5
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_95
  • CPU: x86
  • Submitted: 1998-11-30
  • Updated: 2007-02-20
  • Resolved: 2007-02-20
Related Reports
Duplicate :  
JDK-4093687 - Extension of 'Interface' definition to include class (static) methods.
Duplicate :  
JDK-4193599 - Interfaces need protected and package accessibility
Description

Name: gb36485			Date: 11/30/98


Currently, java interfaces only gracefully supports
*clients* of an interface.  What about the poor soul
who has to *implement* the interface?

There are two user groups of a java interface.
(1) Clients who use the services of an interface
provider.
(2) Developers who implement the services.

Group (1) is served by the Public API.Group (2) should served by a different API with
additional implementation details/requirements.
Most of these extra details cannot currently be
specified, such as:
(a) Constructor arguments
(b) static methods
(c) static attributes
(d) methods with package/protected access.

For example:
interface FlyWeight_WholeValue_Label {
   public static FlyWeight_WholeValue_Label newInstance( String label );
   public boolean equal( Object obj );
   public int hashCode();

   /** each class implementing this interface MUST
    *  provide the following static attributes/methods,
    *  some would be public, most would not.
    **/
   protected FlyWeight_WholeValue_Label( String label );
   static Hashtable register;
   protected void register( String label );
   private setRegister( Hashtable register );
}

Any derived class/interface could access 'protected'
methods,but only the first generation class could
access the private methods and attributes.
(Review ID: 25780)
======================================================================
Comments
EVALUATION The core request here is static methods in interfaces, which is covered elsewhere. As the previous Evaluation said, having constructors and non-public members in an interface is inappropriate.
20-02-2007
WORK AROUND Name: gb36485 Date: 11/30/98 (1)Provide public instance methods to all the above. This totally violates encapsulation and exposes the same API to clients and implementators. It also makes it impossible to vary constants which each class must implement, but which vary from class to class. (2) Make the interface an abstract class. Without MI, this is an expensive and significant choice to make for a class which provides absolutely NO implementation code to its children. ======================================================================
30-09-2004
EVALUATION Certainly, the fact that one cannot require a class to implement certain static methods through an interface creates a displeasing asymmetry wrt to abstract classes. This would be a logical extension. Of course, there would be no way to abstract over the classes that supported this interface. If classes had their own dynamically dispatched (not static) methods, this would be more natural. In any case, I doubt if we'll see such an extension. The other part of this RFE suggests extending this to have interfaces require classes to support certain protected or package private methods is not appropriate. These methods relate to the implementation of a class, and should be provided by each implementation as necessary. gilad.bracha@eng 1998-12-01
01-12-1998