Методы виртуального расширения в следующей версии Java 8

Question

Когда я вижу фрагменты кода, такие как

  interface A {
      void a();
      void b() default { System.out.println("b"); };
      void c() final { System.out.println("c"); };
  }

У меня есть один вопрос. Разве мы не получили достаточно дерьма в Java? Почему это может понадобиться?

Answer 1

Нам это нужно, потому что это сделает парней из Scala абсолютно в ярости. Они уже имеют довольно схожую функциональность в форме «черт», поэтому теперь им придется заставить их работать вместе с ними.

Разозлить парней из Scala - буквально высший приоритет в разработке языка Java.

Answer 2

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

Наличие лямбд, но не возможность легко использовать их со стандартными коллекциями, было бы огромным разочарованием дляJava-разработчики.Для интеграции лямбда-выражений в стандартные коллекции очень желательно использовать методы, такие как forEach, map или filter.

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

Дополнительную информацию о предложении метода расширения можно найти по адресу Предложение по улучшению Java 126 .

Answer 3

Предлагаю вам посмотреть на эту конференцию: http://medianetwork.oracle.com/media/show/16999

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

Answer 4

Это замечательно, потому что это позволяет вам, писателю API, расширять интерфейсы в произвольном порядке, не вызывая NoSuchMethodErrors. Он также обеспечивает реализацию по умолчанию для методов в V2 для классов, скомпилированных с V1; код работает как шарм. Это также позволяет вам переопределить реализацию по умолчанию в классах, скомпилированных для V2, как обычно, и делает нумерованные взаимодействия избыточными. Я считаю, что это также лучше, чем методы расширения сайта.

Answer 5

Я считаю, что концепция «методов расширения» - это не более чем последний шанс взломать / исправить плохо разработанные API, которые были подвержены «внешнему миру».Просто синтаксический сахар.