Quiz yourself: Interface methods and assignment compatibility in Java

What does it mean when a method has no modifiers—and a semicolon instead of a body?

Given these four Java types

package bot;

interface Command {

    String execute();

}

package bot;

public class Engine {

    public static void run(Command c) {

        System.out.println(c.execute());

    }

}

package bot;

import bot.command.AboutCommand;

public class Main {

    public static void main(String[] args) {

        AboutCommand ac = new AboutCommand();

        Engine.run(ac);

    }

}

package bot.command;

public class AboutCommand {

    String execute() {

        return "Chat Bot";

    }

}

What is the result? Choose one.

A. The code successfully compiles and prints Chat Bot.

B. The Command interface fails to compile.

C. The Engine class fails to compile.

D. The Main class fails to compile.

E. The AboutCommand class fails to compile.

Answer. This question investigates the accessibility of interface methods, interface implementation, and assignment compatibility. For this quiz question, look at each of the types that are declared and observe the key characteristics of the sample code.

Starting with the Command interface, notice that the type declaration has no modifier. This gives the interface package-level access, which means that it is accessible only within the bot package.

Next, the execute method is declared with no modifiers and has a semicolon in place of a body. This is valid, and if a method is declared this way in an interface, it will be implicitly public and abstract. From this you can determine that the interface is accessible and valid; therefore, option B is incorrect.

The Engine class is public, so it is accessible anywhere in the same module (or in the same JVM if the code is running without modules). The class declares a single method called run. This method is public, so it’s also accessible anywhere. The method is also static, so no instances of Engine need to be created to use the method. The method takes a single argument of type Command. The Engine class is in the same package as the Command interface, so it is accessible. The body of the run method simply calls the execute method of the Command argument. Command declares that the method, and the usage (the argument type sequence, which is empty), is valid. Because there is no reason for this code to fail, you can determine that option C is incorrect.

Notice that the AboutCommand class is in a different package from the Command interface. In addition, although it has the word Command in its name, this class does not contain the code implements Command. There are two immediate conclusions that can be drawn from this.

◉ Because AboutCommand doesn’t reference Command, it’s not a problem that it’s in a different package.

◉ While AboutCommand is not assignment-compatible with Command, this does not cause a problem here. (It does have consequences in other code, however.)

Also notice that the execute method in AboutCommand has package access and would not be a valid override of the execute method in Command. This isn’t a problem, however, since this method does not attempt such an override.

From these observations, you can see the AboutCommand class compiles successfully and option E is incorrect.

Finally, look at the Main class. It’s in the package bot, so it has access to the Command type. It imports the public type bot.command.AboutCommand, so it has access to that too. The main method has a valid signature line, and that signature is consistent with a program entry point. However, the body of the method has a problem. The argument type for the Engine.run method must be assignment-compatible with Command. However, as noted earlier, AboutCommand does not implement Command; therefore, it is not assignment-compatible with that type. That means the code Engine.run(ac); will fail to compile and option D is correct.

Because the Main class does not compile, option A must be incorrect.

Conclusion. The correct answer is option D.