15

Starting with Java 8, default methods were introduced into interfaces. Effectively, this means that not all methods in an interface are abstract.

Starting with Java 9 (maybe), private methods will be allowed. This means that not all methods in an interface are public abstract.

The question "Should methods in a Java interface be declared with or without the public access modifier?" was asked at Stack Overflow at https://stackoverflow.com/questions/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m

There, most of the answers argued that public abstract should not be used because no method in an interface can be anything other than public abstract. That is no longer the case.

So, in light of these new features of interfaces, should the public abstract keywords be used in a Java interface method declaration?

In my specific environment, we will have people who are experienced software engineers, but not experienced in Java, reading Java code from time to time. I feel that leaving out the public abstract keywords will now create an additional point of confusion for those not familiar with the history of how interfaces came to have different rules for using these keywords.

Improve this question
4
  • 5
    did you check Java 8 JLS? Same section as in old accepted answer at SO suggests that introduction of default methods didn't change prior recommendation which was based on the same redundancy considerations: "An interface method lacking a default modifier or a static modifier is implicitly abstract... It is permitted, but discouraged as a matter of style, to redundantly specify the abstract modifier for such a method declaration." Why do you expect that things should change?
    – gnat
    Aug 3, 2016 at 0:02
  • 3
    I thought things might change because the condition for a method to be implicitly abstract are becoming increasingly convoluted. In Java 9, that same sentence might be, "An interface method lacking a default modifier or a static modifier or a private modifier is implicitly abstract..." Additionally, the auxiliary arguments for not explicitly using the keywords, namely, that all interface methods are public abstract, are now moot.
    – David Campbell
    Aug 3, 2016 at 0:39
  • TBH I don't understand the reasoning behind "default" methods, and even static methods reach outside the scope of what interfaces are normally intended to do. Interfaces aren't supposed to be saddled with concretion. That's why they're useful types for references.
    – Trixie Wolf
    Feb 1, 2017 at 1:03
  • 1
    @TrixieWolf default methods allow interfaces to evolve. Previously, and unlike classes, adding a method would break every implementation; now, you can grow an interface as long as you have a good candidate default. Consider the addition of stream to java.util.Collection, or Map.getOrDefault(). Alternative is to create a new sub-interface, and get everyone to downcast, like Graphics2D, and nobody enjoyed that!
    – SusanW
    Sep 21, 2019 at 22:08

2 Answers 2

Reset to default
3

To expand on the StackOverflow answer:

  1. The public access modifier is not needed because

    Every method declaration in the body of an interface is implicitly public (§6.6). It is permitted, but discouraged as a matter of style, to redundantly specify the public modifier for a method declaration in an interface. (Section 9.4)

  2. The abstract access modifier is not needed because

    A default method is a method that is declared in an interface with the default modifier; its body is always represented by a block.

    And...

    An interface method lacking a default modifier or a static modifier is implicitly abstract, so its body is represented by a semicolon, not a block.

Given that default methods have a body, and those that don't are inherently abstract, and every method declaration on an interface is inherently public, you don't need to specify either keyword.

One of the comments on an answer said:

Don't make them think! I always added public abstract before, despite the style police, cause it made things clear and reminded the reader. Now I am vindicated because Java 8 and 9 complicate things (user949300)

A comment on the StackOverflow question (up-voted 18 times) refutes this:

It's bad because writing it as public implies that it can be non-public (Pacerier)

The implications of code, especially interfaces, are important.

Improve this answer
2
  • The comment you quoted from StackOverflow is now outdated. Saying that adding the public modifier is bad writing since it implies it can be non-public is contradictory. The method can be non-public.
    – David Campbell
    Feb 1, 2017 at 19:36
  • @DavidCampbell: Well, I think this question might be better asked after Java 9 comes out. :) The as-of-yet-to-be-finalized Java spec might answer this question.
    – Greg Burghardt
    Feb 1, 2017 at 20:05
1

Isn't the lack of a block statement implication enough? Would you declare extends Object albeit it's implied?

If the developer does not understand the redundancy, chances are they might not fully understand the concept behind the language feature, which is an even bigger problem than being confused about modifiers.

The developer must understand that the purpose of an interface is to create a contract that defines how a client can interact with an object. This suggests any method in an interface used for object interaction should be exposed to clients.

If you declare a method private, you are explicitly stating that method is not meant to be called by clients, which in the case of interfaces is something that can't easily be inferred.

Improve this answer
12
  • 2
    Don't make them think! I always added public abstract before, despite the style police, cause it made things clear and reminded the reader. Now I am vindicated because Java 8 and 9 complicate things :-). Java is plenty redundant already.
    – user949300
    Nov 1, 2016 at 5:53
  • 1
    @user949300 Would you also add extends Object to every class that directly derives from Object? It's information a developer should already be aware of, which is why it's inferred. The less useless information on the screen, the easier it is to process the important information. Hopefully I've persuaded you to come to the dark side (Get it? Cause implicit stuff can't be seen). If not, it was worth a shot haha. In the end, it comes down to what makes the code easier to manage for the developer
    – Dioxin
    Nov 1, 2016 at 6:06
  • @user949300 By doing this you are more likely to create confusion about what it means when interface methods don't contain these declarations. i.e. if there are any developers learning java by looking at your code, you've potentially hobbled their understanding of the syntax of interface declarations.
    – JimmyJames
    Nov 1, 2016 at 16:08
  • Vince, no, I wouldn't extend Object, though I don't throw a fit when I see code that does so. @JimmyJames, if one is consistent adding public abstract to items that are so, I don't see any confusion. Am I missing something? OTOH, I do see your point on clutter. For example, I don't add final before method arguments unless something funny requires it (like an anonymous inner class etc...)
    – user949300
    Nov 2, 2016 at 0:03
  • @user949300 He means if a user was already exposed to the lack of modifiers and the reason behind it, they may question why the modifiers are there when they see them, making them assume there may be an actual reason behind it other than just being explicit. I wouldn't throw a fit if I saw extends Object, but it would definitely raise a flag and make me question why. As I mentioned in the post, doing such things could imply that the developer may have a misunderstanding of how something works (may not know that all objects already extend Object, hence the explicit extension)
    – Dioxin
    Nov 2, 2016 at 0:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.