Статьи

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

Март 19, 2019
Я некоторое время следил за развитием проекта Java 8 Lambda выражений , и я действительно в восторге от его текущего состояния. Последняя «простая для понимания» презентация, которую я нашел, это:
http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf

Теперь, как дизайнер API, я особенно заинтересован в концепции виртуальных методов расширения, и мне было интересно, предполагается ли также ввести «окончательные» методы расширения в отличие от «стандартных». Например:

1
2
3
4
5
6
7
8
9
interface A {
 
  void a();
 
  void b() default { System.out.println("b"); };
 
  void c() final { System.out.println("c"); };
 
}

При реализации вышеупомянутого интерфейса A один…

  • ДОЛЖЕН также реализовать ()
  • МОЖЕТ реализовать / переопределить b ()
  • НЕ МОЖЕТ переопределить c ()

Преимущества:

  • Разработчики API могут проще создавать удобные методы, не рискуя «незаконным» кодом клиента, переопределяя реализации по умолчанию. Это одна из главных целей «финала».
  • Лямбда-выражения не нужно было бы ограничивать чисто «функциональными интерфейсами» (интерфейсами с одним методом), поскольку функциональный интерфейс по-прежнему был бы «функциональным», если бы у него также было какое-то количество окончательных методов расширения. Например, вышеупомянутый интерфейс A станет функциональным интерфейсом, если b () будет удален или если b () также станет окончательным.
  • Методы расширения будут иметь больше общих черт с обычными методами, которые также могут быть конечными. Я думаю, что для API отражения и для JVM это плюс.
  • В любом случае JVM модифицируется для поддержки методов расширения. Java 8? Импульс можно использовать и для этой функции, то есть сейчас самое время подумать об этом

Недостатки:

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

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

Посмотрите полную почту и продолжение в списке рассылки lambda-dev здесь:

http://mail.openjdk.java.net/pipermail/lambda-dev/2011-December/004426.html

Справка: методы виртуального расширения Java 8 от нашего партнера по JCG Лукаса Эдера из блога JAVA, SQL и AND JOOQ .

Статьи по Теме :

38
Share: