Заключительные аргументы в интерфейсных методах - какой смысл?

В Java совершенно законно определять finalаргументы в интерфейсных методах и не подчиняться таковым в реализующем классе, например:

public interface Foo {
    public void foo(int bar, final int baz);
}

public class FooImpl implements Foo {

    @Override
    public void foo(final int bar, int baz) {
        ...
    }
}

В приведенном выше примере barи bazимеет противоположные finalопределения в классе VS интерфейс.

Таким же образом никакие finalограничения не применяются, когда один метод класса расширяет другой, abstractили нет.

Хотя finalимеет некоторое практическое значение внутри тела метода класса, есть ли смысл указывать finalпараметры метода интерфейса?

Не похоже, что в этом есть смысл. Согласно спецификации языка Java 4.12.4 :

Объявление переменной final может служить полезной документацией, что ее значение не изменится и поможет избежать ошибок программирования.

Однако finalмодификатор параметра метода не упоминается в правилах сопоставления сигнатур переопределенных методов, и он не влияет на вызывающую функцию, только в теле реализации. Также, как отметил Робин в комментарии, finalмодификатор параметра метода не влияет на сгенерированный байт-код. (Это не относится к другим видам использования final.)

Некоторые IDE будут копировать сигнатуру абстрактного / интерфейсного метода при вставке реализующего метода в подкласс.

Я не верю, что это имеет какое-либо значение для компилятора.

РЕДАКТИРОВАТЬ: Хотя я считаю, что это было правдой в прошлом, я не думаю, что текущие IDE делают это больше.

Окончательные аннотации параметров метода всегда имеют отношение только к реализации метода, а не к вызывающему. Следовательно, нет реальной причины использовать их в сигнатурах метода интерфейса. Если вы не хотите следовать одному и тому же последовательному стандарту кодирования, который требует окончательных параметров метода, во всех сигнатурах метода. Тогда это приятно.

Обновление: оригинальный ответ ниже был написан без полного понимания вопроса, и, следовательно, непосредственно не затрагивает вопрос. :)Тем не менее, он должен быть информативным для тех, кто хочет понять общее использование finalключевого слова.

Что касается вопроса, я хотел бы процитировать свой собственный комментарий ниже.

Я считаю, что вы не обязаны реализовывать окончательность аргумента, чтобы вы могли свободно решать, должен ли он быть окончательным или нет в вашей собственной реализации.

Но да, звучит довольно странно, что вы можете объявить это finalв интерфейсе, но сделать это не окончательным в реализации. Это имело бы больше смысла, если бы:

а. finalключевое слово не было разрешено для аргументов интерфейса (абстрактного) метода (но вы можете использовать его в реализации), или
b. объявление аргумента как finalв interface заставит его быть объявленным finalв реализации (но не принудительным для нефинала).

Я могу придумать две причины, по которым у сигнатуры метода могут быть finalпараметры: Бины и Объекты ( На самом деле, они обе являются одной и той же причиной, но немного различаются контекстами. )

Объекты:

public static void main(String[] args) {
    StringBuilder cookingPot = new StringBuilder("Water ");
    addVegetables(cookingPot);
    addChicken(cookingPot);
    System.out.println(cookingPot.toString());
    // ^--- OUTPUT IS: Water Carrot Broccoli Chicken ChickenBroth 
    //      We forgot to add cauliflower. It went into the wrong pot.
}

private static void addVegetables(StringBuilder cookingPot) {
    cookingPot.append("Carrot ");
    cookingPot.append("Broccoli ");
    cookingPot = new StringBuilder(cookingPot.toString());
    //   ^--- Assignment allowed...
    cookingPot.append("Cauliflower ");
}

private static void addChicken(final StringBuilder cookingPot) {
    cookingPot.append("Chicken ");
    //cookingPot = new StringBuilder(cookingPot.toString());
    //     ^---- COMPILATION ERROR! It is final.
    cookingPot.append("ChickenBroth ");
}

finalКлючевое слово гарантировало , что мы не случайно создать новый местный банк для приготовления пищи, показывая ошибку компиляции , когда мы пытались сделать это. Это обеспечило добавление куриного бульона в нашу оригинальную кастрюлю, которую addChickenполучил метод. Сравните это с тем, addVegetablesгде мы потеряли цветную капусту, потому что это добавило это к новому местную кастрюлю вместо оригинальной кастрюли, которую она получила.

Бобы: это та же концепция, что и объекты (как показано выше) . Бобы по сути Objects в Java. Однако bean-компоненты (JavaBeans) используются в различных приложениях в качестве удобного способа хранения и передачи определенной коллекции связанных данных. Подобно тому, как addVegetablesможно испортить процесс приготовления пищи, создав новую кастрюлю StringBuilderи выбросив ее вместе с цветной капустой, он также может сделать то же самое с кастрюлей JavaBean .

Я полагаю, что это может быть лишней деталью, так как окончательная или нет, это деталь реализации.

(Вроде как объявление методов / членов в интерфейсе как public.)