可以从接口中省略公共摘要会损害字节码兼容性吗？

Question

While browsing through SO questions, I came accross the definition of Runnable :

@FunctionalInterface
public interface Runnable {
    /**
     * When an object implementing interface <code>Runnable</code> is used
     * to create a thread, starting the thread causes the object's
     * <code>run</code> method to be called in that separately executing
     * thread.
     * <p>
     * The general contract of the method <code>run</code> is that it may
     * take any action whatsoever.
     *
     * @see     java.lang.Thread#run()
     */
    public abstract void run();
}

As you can see, it has public abstract in the method definition, which are superfluous and, as far as I know , should not be included in method declarations.

I expect the JDK team to have seen this and expect there to be a reason they are still here.

Hence the question, can removing public abstract from interface declarations break bytecode compatability? Keep in mind that this Runnable technically still has to work even with code written using JDK1.0 java code.

Answer 1

I can't find any better source, but here's the JLS for Java 1. (Maybe here .)

Like every other JLS since then, it states.

AbstractMethodDeclaration:

    AbstractMethodModifiers opt ResultType MethodDeclarator Throwsopt ;

AbstractMethodModifiers:

    AbstractMethodModifier

    AbstractMethodModifiers AbstractMethodModifier

AbstractMethodModifier: one of

    public abstract

Notice the opt . It also states

Every method declaration in the body of an interface is implicitly abstract, so its body is always represented by a semicolon, not a block. For compatibility with older versions of Java, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces.

Every method declaration in the body of an interface is implicitly public. It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods.

It will not harm bytecode compatibility.

They probably just wanted to be as explicit as possible.