Why do methods of an interface have to be public?

[Chris Berg]

Why do methods of an interface have to be public? Couldn't they be
'package', or even 'protected'?

The immediate answer would be no, because conceptually, an interface
is a sort of specification that tells the world what to expect from
the implementing class. But why the whole world? Would it not make
sense to limit (at least some of) the methods to 'package' access?
'Protected' would maybe be somewhat more far-fetched, as limiting
access to subclases makes it meaningless to specify the method in the
interface in the first place. Or does it?

But allowing 'package' would allow you to not javadoc all the
interface's methods, some of which could be irrelevant outside the
pakage.

Chris

 

[R.F. Pels]

The immediate answer would be no, because conceptually, an interface
is a sort of specification that tells the world what to expect from
the implementing class. But why the whole world? Would it not make
sense to limit (at least some of) the methods to 'package' access?

Well, maybe, but OTOH, I think the main reason for it is to provide a handle
for implementers and the implementation class will probably not reside in
the same package.

'Protected' would maybe be somewhat more far-fetched, as limiting
access to subclases makes it meaningless to specify the method in the
interface in the first place. Or does it?

Protected methods aren't exactly part of a classes' interface, right?

 

[Roedy Green]

Why do methods of an interface have to be public? Couldn't they be
'package', or even 'protected'?

It make sense they can't be private. You need two classes to have an
Interface.


Protected would be tricky to define.

Why not package? The idea is that interfaces are supposed to allow
third parties to write code that will plug in, without any of the
other supporting code.

Perhaps that notion was so strong Sun refused to consider package
interfaces.

That rule does force you to make public stuff that clients of your
class have no business using.

The problem perhaps more is that you want to expose some interfaces
only to Sun, but once they are public, everyone can see them.

 

[Oliver Wong]

Why do methods of an interface have to be public? Couldn't they be
'package', or even 'protected'?

I'd imagine an interface's method whose visibility was "package" is ill
defined. Whose package? The package of the class using the interface? The
package of the interface itself? The package of the class implementing the
interface?

But allowing 'package' would allow you to not javadoc all the
interface's methods, some of which could be irrelevant outside the
pakage.

If you don't want your interface used outside of the package, make the
interface itself have package visibility, as opposed to its methods.

If you need some of the methods to be public and some to be package
visible, make two interfaces, and have your classes implement both.

- Oliver

 

[Roedy Green]

I'd imagine an interface's method whose visibility was "package" is ill
defined. Whose package? The package of the class using the interface? The
package of the interface itself?

You would define it so that only classes in the same package as the
interface name on the interface declaration could use it. It would
works the same as a package scope class.

The clue may be that there are two places rules are enforced, in the
JVM and in the language. Sun are usually more interested in enforcing
at the JNM level than the language level.

If you look at the class file structure, it may become clear why
protected interfaces don't exist.

 

[John C. Bollinger]

You would define it so that only classes in the same package as the
interface name on the interface declaration could use it. It would
works the same as a package scope class.

Which would be fine for *using* implementations, but totally unworkable
for *writing* them. You snipped some of the more insightful of Oliver's
comments:

Overall, the constraints on interfaces ensure that anyone who can see an
interface can see *all* of it, while still allowing normal restriction
of the visibility of the interface itself.

The clue may be that there are two places rules are enforced, in the
JVM and in the language. Sun are usually more interested in enforcing
at the JNM level than the language level.

If you look at the class file structure, it may become clear why
protected interfaces don't exist.

Protected interfaces do exist, at least at the language level, and
enough at the classfile level that the compiler, at least, can perform
correct access control on them. Like protected classes (or indeed,
protected anything), protected interfaces must be be class members.

 

[Roedy Green]

You snipped some of the more insightful of Oliver's
comments:

I only quote what I am commenting on. I wish others would do
likewise.

There is too much to read already without people repeating it.

 

[Dale King]

It make sense they can't be private. You need two classes to have an
Interface.

Private would make as much sense as package actually. The classes that
implement the interface could actually be nested classes within the
interface that would have access to the private members of the interface
(if such a thing were permitted). But of course nested classes did not
actually exist at the time interfaces were created.

Why not package? The idea is that interfaces are supposed to allow
third parties to write code that will plug in, without any of the
other supporting code.

I think the answer to this is that if you have methods that you want to
be limited to the package that instead of declaring the methods package
that you split the interface into one that is public and one that is
package access and implement the two interfaces. This does not address
all the reasons why you might want less than public members in an
interface, but does address some.