Package-level Interface Implementation - why public?

[jims@xxxxxxxxx (Jim Scarborough)]

"Deever, Chris C." wrote:

> Any insights as to why implemented interface methods *must* be public?
> There must be design reason for this, but I can't think of one.

Hi Chris,

I just ran across the same peculiarity.  (My Java 1.2.1 compiler (Sun's on
WinNT) tacitly promotes interface methods without access modifiers to public.)
Of course private methods don't make sense in interfaces, and neither do
protected methods.  Package methods on the other hand, could be useful to other
classes within the package.

How about giving the interface itself package scope?  Then a public interface
offers the public methods, and the package scope interface (which extends the
public interface) provides package accessibility.  Like this:

public interface A {
   ...
}

interface B extends A {
   ...
}

You can't access interface B from outside B's package (so my compiler confirms).

It seems reasonable that having one way to solve the problem is sufficient, but
this solution isn't equivalent to marking the methods package accessibility.  It
amounts to a messy way to go about hiding methods that can only be hidden
halfway. You have to declare all of interface B's methods public in your
implementation (lest you attempt to reduce its accessibility).  Everything can
see the implementation methods, but nothing can see the interface that ties them
together.

Arnold and Gosling, in _The_Java_Programming_Language_Second_Edition_ (Addison
Wesley, 1998), spell out why interface methods must be abstract, but they only
assert that the methods must be public without explanation.  Perhaps another
reference offers more insight.

A side note on the package access modifier:  The package (default) access
modifier doesn't allow access to descendant classes in other packages.  A number
of work candidates I've interviewed say package modifiers are also accessible to
descendants - presumably because they just read it in a Java test preparation
book with that error in it.

Jim


---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx