Несоответствующий интерфейс и подпись реализации

1

Что произойдет, если в jar есть интерфейс с методом, реализованным классом в другой банке, и добавленный интерфейс добавляет исключение проверки и развертывается без перекомпиляции класса реализации?

  • 0
    Очень хороший вопрос Один из тех редких, которые заставили меня немного подумать после использования Java более 15 лет. Тем не менее, если бы я поймал вас на том, что вы делаете это в моей команде, я бы резюмировал это следующим образом:
Теги:
jar
interface

1 ответ

0

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

Однако это действительная Java

public interface GetFive {

  int getFive() throws Exception;

}

public class GetFiveImpl implements GetFive {

  int getFive() {
     return 5;
  }
}

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

GetFive.getFive() использование GetFive.getFive() в блоке, который не вызывает исключения. GetFiveImpl.getFive() в блоке не может исключить исключение.

Даже если бы у вас был блок, который работал на интерфейсе, этот блок был скомпилирован в среде, где исключение никогда не могло быть поднято; так что все будет хорошо. Тем не менее, я бы не стал распространять эту практику.

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню