JDK 8 в примерах

[Maccimo]

interface Iterator {
…
default { throw new UnsupportedOperationException(); };
...
Тревожный звоночек.
Засыпаем всё сахаром, что бы индусу (в плохом смысле этого слова) было удобно.

[shambho]

Да нормально, в Котлине тоже можно реализовывать методы интерфейса.

[Maccimo]

Kotlin всё же не Java.
Хочет JetBrains потренироваться в создании своего диалекта с шахматами и поэтессами — их право.

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

В том же PHP, не к ночи будет помянут, для схожей фичи не cтали городить интерфейсы-мутанты, а ввели новое ключевое слово trait.

[akuznetsov]

Это не множественное наследование, а скорее миксины. Они уже давно есть в ruby, scala и других языках.

[edelweard]

trait — не новое слово ;) en.wikipedia.org/wiki/Trait_(computer_programming)

[Maccimo]

Я писал про новое ключевое слово в PHP, а не новое слово в программировании :)
То, что трайты изобретены задолго до того, как они появидись в PHP, я знаю.

[EgorK]

Синтаксический сахар — это то, что можно сделать как-то по другому, просто сложнее/некрасивее
В данном случае вводится по сути множественное наследование по имплементации (не по данным), чего современными средствами сделать нельзя

[darkazazello]

Если современные средства имеется ввиду ява — это верно. В хаскеле уже давным давно множественное наследование по фукнциональности

[stoune]

extension methods в .NET есть уже два года с .NET 3.5 и ничего страшного.

[mefcorvi]

Это, увы, не extension. Это абстрактный класс с поддержкой множественного наследования. Т.е. интерфейс теперь определяет не только «что» должна делать реализация, но теперь ещё и частично «как». В общем, зря они это затеяли. Какой-то костыль для поддержания обратной совместимости.

[alexeyrom]

Нет, «как» должна, не определяет. Только как может. И отличие от методов расширения .Net здесь, по-моему, в пользу Java.

[mefcorvi]

Ну да, только «как может», поэтому я и написал «частично». Мне кажется вариант с опциональными методами и возможностью проверки того, реализует класс метод, или нет, был бы чище с точки зрения ООП. Пусть даже без возможности проверки, а с выбрасыванием исключения, как это приведено в примере в посте, но только с выбросом исключения, без какой-либо логики.

Методы-расширения в шарпе — это чистейший синтаксический сахар, на интерфейс и класс они не влияют, они вообще не изменяют контракт. Даже лежат чаще всего в отдельном пространстве имён.

[WFrag]

Могу ли я добавить новый метод с дефолтной реализацией в интерфейс не ломая старый класс?

Было: interface A { foo(); }; class B implements A { foo() {...} }
Стало: interface A {foo(); bar() default {...} }
Делаем: A a = new B(); a.bar();

Будет работать?

[mefcorvi]

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

[trg]

Java #.

[shambho]

Нифига не упрощение многопоточности. Просто ещё один 15 способ. Вот сделают как в Erlang — тогда да. А сейчас Java не готова к массовой многопоточности.

[Lendon]

Нифига не упрощение многопоточности.

Теперь различные API(в том числе JDK) смогут вводить многопоточность прозрачно для клиентского кода.

А сейчас Java не готова к массовой многопоточности.

Современный мир требует повышения производительности и предоставляет для этого все условия(современные процессоры). Все внешние условия для массовой многопоточности созданы. Можете объяснить что значит «Java не готова»?

[shambho]

> Можете объяснить что значит «Java не готова»?

Сравните JSR-133 и !/receive из Erlang. Модель акторов хорошо масштабируется, например на 144-ядерный процессор Мура. В Java поломается голова от учёта всех тонкостей при синхронизации, посмотрите исходники java.util.concurrent для примера.

[aleks_raiden]

для акторов в java есть Akka )

[shambho]

Akka поднимет 1 000 000 параллельных соединений?

[aleks_raiden]

да. хотя это уже проблема не только языка но и всей платформы. urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/

[Foror]

Да хоть 10 000 000, только не забудьте вначале стек для каждой нити сделать поменьше, ибо дефолтный что-то около 512Кб на одну нить — никакой памяти не хватит :)

[alist]

Java Джаве рознь. Например, Vega 3 от Azul еще в 2008 году скейлилась на 54 ядра и 640 гигов для одной виртуальной машины. Да, тогда это требовало наличия особого железа (с поддержкой read barriers), но затем они смогли перенести свое решение на обычный x86.

У них самый быстрый и стабильный GC — C4 — никаких Stop-the-World пауз вообще.

С точки зрения конкурентного выполнения у Java есть гораздо больше средств в арсенале. Ниже вам сказали про Akka — та же actor model. Кроме нее есть Hadoop, Fork/Join, Clojure Agents и STM. java.util.concurrent — это низкоуровневое API, и никто не заставляет вас им пользоваться.

При этом скорость выполнения кода в Java обгоняет Эрланг в разы (примерно в 5 раз, если верить бэнчмаркам). Т.е. одну и ту же задачу можно решить на Эрланге, имея 20 серверов, и на Java, имея 4 сервера.

[shambho]

Вопрос не в производительности. Сейчас скриптовые языки переходят на свои внутренние виртуальные машины, что постепенно поднимает производительность.

Вопрос в сложности разработки. Проще и дешевле прикупить дополнительный сервер под Erlang, чем геморроить мозг синхронизацией потоков на Java.

[ScratchBoom]

Вы на джаве хоть раз писали?

[shambho]

Я конечно начинающий, пол-года, но многопоточностью интересуюсь, и на java, и до этого на других языках, в том числе на Erlang. После Erlang не понимаю, зачем люди усложняют себе жизнь. Встречный вопрос: Вы на Erlang хоть один сервер написали?

[WFrag]

А вы? Завления про «чудесную» масштабируемость Erlang-а несколько настораживают.

Чуда не произойдёт, последовательная программа, будучи переписанной на Erlang, не станет имспользовать 144 ядра. С другой стороны, программа, которая независимо обрабатывает 1000 клиентов одновременно и на Java заиспользует все ядра, коли потребуется.

Erlang — замечательный язык, но, по-моему, его плюсы не совсем там, где их обычно ищут.

[shambho]

Мы говорим немного о разном. Есть три эквивалентных спобоса взаимодействия в многопоточночти (навскидку, могу и ошибаться): мониторы, семафоры, очередь сообщений. Они эквивалентны в том смысле, что на любом из них можно реализовать два других. Мой основной тезис: мой опыт (и отзывы других людей, изучавших Erlang) показывает, что сложность разработки программ на Erlang с очередью сообщений намного проще (и интуитивнее), чем на мониторах Java. Имеет в виду не распараллеливание семанантически последовательных программ, а программирование именно сложных межпоточных взаимодействий.

Да, на Java тоже есть акторы, но в Erlang они «родные», хорошо интегрированы в язык, более читабельны (благодаря плюшкам Erlang-а в виде нетипизированности, паттерного присваивания и т.д.).

Про плюсы я в курсе. Свой шедуллер, не «зелёный». Вроде хотят сделать свой GC в каждом потоке. (почти) функциональный стиль с одноразовым присваиванием сильно упрощает GC, делает кучу малофрагментизированной.

[WFrag]

>Проще и дешевле прикупить дополнительный сервер под Erlang, чем геморроить мозг синхронизацией потоков на Java.

Ну разумеется, дешевле: lionet.livejournal.com/88113.html

[shambho]

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

[xonix]

Множественное наследование в моей ламповой яве. Нет пути. Дотянулся проклятый Оракл.

[xappymah]

Зря так сильно на Оракл плюетесь. Возможно не самая лучшая корпорация с не самыми лучшими решениями, но по крайней мере они одно сделали хорошо: простимулировали очень бурное развитие Java, которое очень было необходимо в текущих реалиях.

[lxyd]

Могу только предположить, что там это сделано как в .NET, т.е. метод-расширение может использовать только методы интерфейса, без конкретной реализации, без полей и т.д. А это значит, что такой подход не хуже, чем вызов статического метода другого класса, только нагляднее (в .NET оно так и есть: метод-расширение — это статический метод левого класса со специально помеченным первым аргументом).

[aymeshkov]

Дай бог чтобы было именно так. То, как это сейчас описано, меня пугает.

[lxyd]

А по-другому как?
Дефолтная реализация ничего не знает о конкретной, т.е. использовать может только методы самого интерфейса. Ну, по логике — так, а как по факту — посмотрим.

[aymeshkov]

Вроде как вы правы, посмотрим что получится.

[xappymah]

На этом основные мажорные фичи восьмерки заканчиваются.

Ничего себе «заканчиваются». А как же разбиение на модули, method handles и invokedynamic?
Это не менее мажорные фичи.

[Beholder]

Method handles и invokedynamic уже. В JDK 7.

[aymeshkov]

Я сейчас скажу достаточно спорную штуку, но все-таки: java в последнее время потихоньку перенимает у c# разные полезные фичи (поменялись они местами, да:)), но почему-то каждый раз через жопу.

Generic'и — вместо того, чтобы стянуть один-в-один поленились и сделали через приведение типов.
Имхо реализация generic'ов в шарпе более продумана.

Теперь extension-методы. Нет бы стянуть из шарпа, где это простая фича, по сути — это упрощение синтаксиса и не более. Но [i]множественное наследование[i] ради возможности писать типа-какбы-в-функциональном-стиле?

Ой не к добру, не к добру.

P.S. И еще, дорогие разработчики языка, если уж вы начали добавлять синтаксический сахар, где Properties вашу мать?

[Lendon]

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

[dokwork]

Вот за Properties полностью поддерживаю!

[leventov]

Properties (и indexers) — синтаксический яд.

[dokwork]

а обосновать?

[aymeshkov]

а зачем? это утверждение из разряда религиозных, такие не обосновывают:).

[Stocker]

Generic'и в java такие, какие есть из-за обратной совместимости.

[aymeshkov]

MS пошли по другому пути, и, для сохранения обратной совместимости рядом с System.Collections появился System.Collections.Generic.

Чем вас не устраивает такой подход?

[alno]

> Generic'и — вместо того, чтобы стянуть один-в-один поленились…

.NET 2.0 — 2005-11-07
J2SE 5.0 — 2004-09-30

[aymeshkov]

Черт побери, я заблуждался:)

Спасибо, не знаю почему, но думал, что шарп был первым).

[randoom]

Вы не одиноки ;)

[lxyd]

Вообще, здорово!

Давно не писал ничего на Java, но боялся даже представить как тяжко будет в случае необходимости на неё возвращаться после Linq'а в .NET (имею в виду не встраиваемые запросы с отдельным синтаксисом, а сопутствующие методы-расширения коллекций: Where, OrderBy, ToDictionary и т.д.)
Теперь перспектива уже не такая пугающая.

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

[dokwork]

почему не добавят event, как в шарпе? их порой оочень не хватает.

[aymeshkov]

Где-то читал интервью одного из разработчиков языка, он говорил что event'ы и делегаты это не православно, и в java их никогда не будет. Так что addListener и тысячи строк лишнего когда с нами навсегда:).

[alexeyrom]

А в чём, по-вашему, отличие тех лямбд, которые добавляются в JDK 8 от делегатов?

[Colwin]

Сразу вопрос.
Если в интерфейсы добавятся default-методы, то чем они будут отличаться от абстрактных классов?

[Colwin]

И из какого интерфейса наследовать default-реализацию при совпадении сигнатуры методов?

[lxyd]

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

[Lendon]

При пересечении default-реализаций будет использоваться реализация более специфического интерфейса. К примеру если интейрфейс B extends A, то интерфейс B более специфический.
Если возникнет конфликт методов между супер-классом и супер-интерфейсом, то метод супер-класса имеет более высокий приоритет.

[lxyd]

А если наследовать класс от двух интерфейсов, у которых есть методы с одинаковыми сигнатурами и разными дефолтными реализациями (ни один из них не «более специфичный»), что тогда?
Речь, собственно, о том случае, когда все варианты равны и выбрать тот, который равнее, автоматически не получится.

[Lendon]

В таком случае программисту необходимо определить прокси-метод в котором нужно использовать нововведенную в JDK 8 конструкцию X.super.foo()
Пример:

interface A { void foo() default ...; }
interface B { void foo() default ...; }
class C implements A, B {
  /* required */ public void foo() { A.super.foo(); }
}

P.S. Не сочтите ленью описывать в топике. Моей целью было вкратце осветить основные фичи восьмерки. Если бы я написал о всех фичах, то это было бы похоже на топик-перевод презентации. Кому интересно, тот может посмотреть презентацию и узнать все интересующие его детали.

[helions8]

Тем, что теперь интерфейс фактически является миксином (или trait в терминологии Scala), и «подмешать» к классу можно произвольное количество, что в случае с абстрактным классом все же не получится.

[Colwin]

Т.е. определением только поведения и отсутствием состояния.

[Megaprog]

Хорошая статья, несмотря на то, что автор забыл упомянуть о таких важных нововведениях как Project Jigsaw (модульная система) и JavaFX 3.0 (новый GUI). По моему мнению Java пытается развиваться не сколько вслед за C#, а в большей мере по стопам Scala, где все представленные фичи (в частности traits и closures) уже давно существуют и пользоваться ими можно уже сейчас, не дожидаясь 2013 года (когда Oracle нам обещает Java SE 8). Что касается упомянутой здесь библиотеки akka, то она заточена в большей степени опять же под Scala, для Java там меньше возможностей. Но в любом случае, меня радует, что Java не остановилась на месте, а развивается, пусть не так быстро и не в ту сторону, куда хотелось бы.

[intr13]

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

Писал я на java в функциональном стиле, lambdaj и подобное ему пользовал. Фигня это все, у начинающих программистов мозг плавиться (а опытные коллеги по голове бьют). Да и для нетвиальных штук приходится так извращаться, что плакать хочется (эмо наше все).

Кстати, многопоточность это конечно хорошо, но надо ее явно использовать. Иначе индусы студенты напишут такую лапшу, что все подавяться только. Проще надо быть, проще!

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

Ну и конечно ООП наше все, ведь красивый код это красиво. Программисты это любят, написал говнокод, а потом его рефакторишь, хотя иногда надо просто выкинуть все и сызнова написать. Средства не всегда оправдывают цель. Вы меня конечно извините, но говно все эти (именно это) изменения, маркетинг сплошной.

[aspect]

только всё наоборот, жаба становится не более объектно-ориентированной, а более функциональной: всяческие лямбы, мапы и фильтры