(perhaps) Dumb interface question

[DemmeGod]

This concerns visibility level for interface methods. I've got an
interface, with a method defined as so:
void method1();

Normally, this would be package-level visibility, however upon
implementing this interface, I am forced to make the method public.
When I make it package, the compiler yells at me saying that I'm
attempting to assign a weaker access level which strikes me as really
bizarre. If it makes any difference, both the interface and the
implementing class are in the same package. Is there something weird
going on here, or is my ignorance flaring up?

Thanks,
John

 

[Adam Maass]

This concerns visibility level for interface methods. I've got an
interface, with a method defined as so:
void method1();

Normally, this would be package-level visibility, however upon
implementing this interface, I am forced to make the method public.
When I make it package, the compiler yells at me saying that I'm
attempting to assign a weaker access level which strikes me as really
bizarre. If it makes any difference, both the interface and the
implementing class are in the same package. Is there something weird
going on here, or is my ignorance flaring up?

All methods in interfaces are implicitly public, even if the interface
itself is not.


-- Adam Maass

 

[A Bag Of Memes]

This concerns visibility level for interface methods. I've got an
interface, with a method defined as so:
void method1();

Normally, this would be package-level visibility, however upon
implementing this interface, I am forced to make the method public.
When I make it package, the compiler yells at me saying that I'm
attempting to assign a weaker access level which strikes me as really
bizarre. If it makes any difference, both the interface and the
implementing class are in the same package. Is there something weird
going on here, or is my ignorance flaring up?

From JLS 9.4:
Every method declaration in the body of an interface is implicitly public.

 

[xarax]

This concerns visibility level for interface methods. I've got an
interface, with a method defined as so:
void method1();

Normally, this would be package-level visibility, however upon
implementing this interface, I am forced to make the method public.
When I make it package, the compiler yells at me saying that I'm
attempting to assign a weaker access level which strikes me as really
bizarre. If it makes any difference, both the interface and the
implementing class are in the same package. Is there something weird
going on here, or is my ignorance flaring up?

Thanks,
John

As others have already stated, everything in an interface
is public by default. This is a design blunder in Java
that allows the "abstract", "public" and "static" specifiers
to be implied in an interface, yet required in a class to get
the same effect. To rub salt in the wound, the Java Lang
Spec even has a style recommendation to leave off those
specifiers in an interface. Stupid.

I *always* fully specify the "abstract", "public", and
"static" keywords in my interfaces, even though Sun doesn't
like it. It makes easy work to copy&paste those declarations
into my abstract classes that implement the interface. Then
I can edit individual methods in the abstract class as needed,
filling in the bodies and removing the "abstract" keyword.

btw: The "abstract" keyword seems redundant, since a compiler
should be able to determine that a method is abstract or
concrete by whether it is followed by a semi-colon or a
curly brace block {}. Oh, well.

 

[Roedy Green]

btw: The "abstract" keyword seems redundant, since a compiler
should be able to determine that a method is abstract or
concrete by whether it is followed by a semi-colon or a
curly brace block {}. Oh, well.

Abstract is primarily for you, not the compiler. When the compiler
tells you a class cannot be instantiated because it is a abstract, you
want to know if that was intentional or an accident -- you misspelled
the name of some overriding method.

 

[Miguel De Anda]

This concerns visibility level for interface methods. I've got an
interface, with a method defined as so:
void method1();

Normally, this would be package-level visibility, however upon
implementing this interface, I am forced to make the method public.
When I make it package, the compiler yells at me saying that I'm
attempting to assign a weaker access level which strikes me as really
bizarre. If it makes any difference, both the interface and the
implementing class are in the same package. Is there something weird
going on here, or is my ignorance flaring up?

Thanks,
John

Right. If you interface is in package a.b.c and the class that implements it
is in a.b.d, then what package can see the "package-level" items? What if
another class implements it at package a.b.e? I think it makes perfect sense
for interfaces to be designed this way.

 

[DemmeGod]

Right. If you interface is in package a.b.c and the class that implements it
is in a.b.d, then what package can see the "package-level" items? What if
another class implements it at package a.b.e? I think it makes perfect sense
for interfaces to be designed this way.

I disagree. In the implementation, if it's package-level, other
classes in the implementation's package should be able to see it. Why
should the interface's fellow classes have to see it? Although this
is not necessarily useful is many cases, in my case this public crap
is a major pain in the ass.

John

 

[A Bag Of Memes]

(e-mail address removed) (DemmeGod) wrote in message

As others have already stated, everything in an interface
is public by default. This is a design blunder in Java
that allows the "abstract", "public" and "static" specifiers
to be implied in an interface, yet required in a class to get
the same effect. To rub salt in the wound, the Java Lang
Spec even has a style recommendation to leave off those
specifiers in an interface. Stupid.

Not stupid. Every method in an interface declaration is abstract and public
and none of them can be static. It's redundant to put them in the code. We
know they are abstract public non-static methods because they are defined in
an interface.

I *always* fully specify the "abstract", "public", and
"static" keywords in my interfaces, even though Sun doesn't
like it. It makes easy work to copy&paste those declarations
into my abstract classes that implement the interface. Then
I can edit individual methods in the abstract class as needed,
filling in the bodies and removing the "abstract" keyword.

I suggest giving Idea or Eclipse a shot. No more cut and paste. Hot keys
pop up a menu to add methods from interfaces, complete with the correct
qualifiers.

 

[pete kirkham]

btw: The "abstract" keyword seems redundant, since a compiler
should be able to determine that a method is abstract or
concrete by whether it is followed by a semi-colon or a
curly brace block {}. Oh, well.

True, though without the redundancy you might get up to one case such as
per .java file:

class Foo {
public void bar (); {
// method body here;
}
}

So the redundancy may do some good.

At least half the engines on an airliner are redundant.


Pete

 

[Adam Maass]

It would offer more flexibility for all the methods in an interface to
share the access qualifier of the interface, limited to public or
package. In the case where an interface should be available to be
implemented outside it's defining package it would be public, where it's
an implementation accident with use restricted to one particular
package, its methods would be able too be defined as package access.

This would have the effect of allowing the implementations of the
package-specific interface methods to have package-specific access,
rather than forcing them to be public when thet are not part of the
contract between the package and the outside world.

An issue only when the implementing class (or a subclass of the implementing
class) is public, and the methods implementing the interface should not
appear in the public contract of the class.

You could refactor this class into the part that is conceptually public, and
the part that needs to implement the interface. This second part would be
moved into an inner class that implements the interface, and instances of
such inner class would have the same lifetime as the enclosing instance. The
inner object's methods would be invoked as necessary.


Granted, this is not a particularly elegant solution to the problem, but it
does avoid unnecessarily contaminating the public interface of a class with
methods implementing an interface.


-- Adam Maass

 

[xarax]

Not stupid. Every method in an interface declaration is abstract and public
and none of them can be static. It's redundant to put them in the code. We
know they are abstract public non-static methods because they are defined in
an interface.

/snip/

Of course, it's stupid. You cannot convince me otherwise. It's
not an issue of redundancy, but rather lack of consistency.
It's water under the bridge, anyway.

Cheers...

 

[Dale King]

This concerns visibility level for interface methods. I've got an
interface, with a method defined as so:
void method1();

Normally, this would be package-level visibility, however upon
implementing this interface, I am forced to make the method public.
When I make it package, the compiler yells at me saying that I'm
attempting to assign a weaker access level which strikes me as really
bizarre. If it makes any difference, both the interface and the
implementing class are in the same package. Is there something weird
going on here, or is my ignorance flaring up?

Basically, you need to move the visibility specification to the interface
itself instead of the individual methods. If all method declarations are
supposed to only be package-level then you make the interface itself
default visibility instead of public. If you want some methods to be
public and some package you should split it into a public interface and a
package-level interface that extends the public interface.