46

Do all methods in an Interface has by default Public visibility mode?

developer
  • 9,116
  • 29
  • 91
  • 150
  • If you have time, you might want to read SCJP for java 6 prep guide by head first team. A lot of info there. The interface methods are abstract and public by default. – zawhtut Mar 24 '11 at 12:43

5 Answers5

81

All methods in an interface default to public.

See Java Language Specification 6.6.1 which states

All members of interfaces are implicitly public.

Pang
  • 9,564
  • 146
  • 81
  • 122
Jeff Foster
  • 43,770
  • 11
  • 86
  • 103
16

All interface methods ARE public abstract, all interface fields are public static final...

see here.

pgras
  • 12,614
  • 4
  • 38
  • 46
  • 1
    It is best not to have any state (instance variables) in an interface, though the compiler will let you define fields. An interface should define capabilities, or what the object can do. – hotshot309 Dec 04 '12 at 19:31
12

Just to add to other answers here: all methods are public, however, if the interface itself is package-local then effectively all methods are also package-local.

You can therefore mix public and package-local methods, by making a package-local interface extend a public one.

public interface P{
  void iAmPublic();
}

interface L extends P{
  void iAmPackageLocal();
}

Here L effectively has one public and one package-local method. Clients from outside the package will only see iAmPublic(), whereas ones from inside the package will see both methods.

In the same way you can nest interfaces inside other classes to achieve even tighter method visibility.

rodion
  • 14,729
  • 3
  • 53
  • 55
  • 1
    your method `iAmPackageLocal` will _not_ be package-private. See http://stackoverflow.com/a/4801672/16209 – Aleksey Otrubennikov Dec 30 '11 at 15:02
  • 2
    As I have stated in the first sentence the method is *effectively* package-private (note the word **effectively** here) since methods cannot exist without their declaring interface, which can be package-private as stated in the same post. As you can only access `P#iAmPublic()` from outside the package, but can access both methods from inside the package, you get the desired effect. Say you have some API with a method `public L getL();` within the package, and then try calling `getL().iAmPackageLocal()` from outside the package you will get a compiler error. – rodion Jan 08 '12 at 11:41
  • `public class PseudoPrivate implements L – Aleksey Otrubennikov Jan 10 '12 at 13:30
  • This can leak with `public class PseudoPrivate implements L`. And then from outside the package this will work: `new PseudoPrivate().iAmPackageLocal();` – Aleksey Otrubennikov Jan 10 '12 at 13:36
  • 1
    You are right, but I think this one is a matter of opinion, because it's the designers choice whether to expose the implementation class (`PseudoPrivate` in this case). If you were going to expose implementation class why did you use interface in the first place? Right? So if you stick to using the interfaces as your public API, then there is no problem, as far as I see it. – rodion Jan 11 '12 at 04:51
  • `public interface PseudoPrivate extends L`? – Aleksey Otrubennikov Jan 12 '12 at 15:11
  • OK, you got me there:) ... I still do you use this technique quite often as it's useful (as long as you take care not to leak visibility:)). It's a shame that Java doesn't have a nicer way of doing this. – rodion Jan 13 '12 at 00:31
  • @rodion But he didn't get you there, did he? The `extends L` example still requires `PseudoPrivate` to be in the same package (so that `L` is accessible), so it's the same issue as with the `implements L` one (i.e., would only happen by choice of the designer). – Stuart Rossiter Oct 31 '14 at 14:59
  • 1
    @monsieurRigsby What he's trying to point out is that, my idea works only when you have `L extends P`, and not `P extends L` as that will leak visibility. It's a valid point. But the idea still works provided you strictly stick with `L extends P` in your code. – rodion Nov 14 '14 at 08:58
  • @rodion I don't follow you. Your basic design is package-access interface `L` extends public interface `P` for pseudo-package-access `L` methods. Both `PseudoPrivate implements L` *and* `PseudoPrivate extends L` leak visibility, but *both* require `PseudoPrivate` to be in the same package, and thus both would only exist as a package-designer decision (as you mention) and thus don't really compromise the general idea. – Stuart Rossiter Nov 17 '14 at 10:25
  • @rodio Can you use the package-private interface outside of the package? i.e. L myObj = new objThatImplementsL(); This wont work unless it's in the same package as L will it? If thats the case, then how is there both a public and package-private method, since the interface L can only be used in the same package? – TigerBear Aug 18 '15 at 18:41
  • @monsieurRigsby you could argue that one could unintentionally leak visibility (another developer could be oblivious to the package-access visibility of `L`). Also, the visibility leaking behaviour only occurs in interfaces and not in classes, which underlines that interfaces were not designed with this kind of usage in mind. It seems more like an "unintended feature", so one should probably use it with care. – rodion Sep 14 '15 at 03:24
  • @punchingInAPepper No, `L` cannot be used outside of the package. The original idea was to declare an interface `L` that would have methods only visible and usable from inside the package. Here is a working example that makes the idea useful: 1) Declare a `public interface X { P getP(); }` 2) Declare a `public class C implements X { public L getP(); }`. From outside the package you would only be able to do `X x = ...; x.getP().iAmPublic();`. From inside the package you could optionally do `C c = ...; c.getP().iAmPackageLocal()`. – rodion Sep 14 '15 at 04:41
4

Yes, all methods of an interface are public, and can't have any other access modifier (i.e. the default public access modifier is the only valid access modifier)

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
3

Yes, all methods in an interface are implicitly public and abstract.

Check Java language specification chapter 9.4

Kojotak
  • 2,020
  • 2
  • 16
  • 29