elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
По следам JavaOne: Что ждать от Java 7 (Часть 1: Closures)
elizarov
Сразу оговорюсь, что скоро ждать Java 7 не нужно. Компания Sun Microsystems ударилась в конкуренцию с компанией Adobe и направила все свои лучшие силы на развитие технологии JavaFX. В этом посте я не буду углубляться в обсуждение этого факта и предсказывать победителей, скажу лишь что core Java, в том числе и Java 7, тоже в чем-то от этого выиграет (или проиграет -- это как посмотреть). Сейчас же я поговорю о тех планируемых улучшениях, которые ни как не связаны с технологией JavaFX.

Наиболее радикальным и фундаментальным изменением которое могло бы произойти в Java 7 была бы поддержка в языке Closures. Смотрите доклад Нила Гафтера Closures Cookbook. Более подробная информация, включая прототип реализации находится на www.javac.info. Лично мне не нравится предложенный авторами синтаксис, но даже с таким синтаксом язык Java безусловно улучшится. Я могу назвать массу мест в своем собсвтенном коде, где можно было бы сократить boilerplate код, если бы в языке была поддержка closures. Однако, с большой вероятностью closures в Java 7 все-таки не появятся. Соответсвующее предложение еще даже не зарегестрировано через JCP.
Tags:

  • 1
у меня почему то какое то интуитивное ощущение, что Java начала медленно но верно сдавать позиции.. я бы на месте Sun направление JavaFX закрыл бы нафиг, так как внятных use cases для неё нет и не предвидится, только очередная надстройка над надстройкой

Да почему, создание UI отличный юз кейс. На Java вещи вроде data binding и создания иерархии компонентов внятно описать трудно. Польза на лицо.

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

Джава упорно идет своим путем.

ну и до кучи функциональности... Действительно, я зыков где всякой функциональности до кучи последнее время появилось много. [Не решенная?] проблема в том, как при этом сохранить простоту и понятность языка. Хорошая иллюстрация это Scala. Вроде замечательный новый язык на замену Java, но такой сложный, что даже разаботчики популярных IDE ропчут.

Про ропчущих разработчиков читал. Не зря ропчут - единственная платная ide не справляется с объемом. Тут тебе и сонм веб-фреймворков (например, http://wicket.apache.org/introduction.html), и множество скриптовых языков, да и конкуренты поджимают. Седьмая версия тормозит неподецки и некоторые из моих знакомых уже переползают на эклипс. С трудом верится, что платная версия поборет "бесплатное" коммьюнити. Но лучшая ide пока остается ей. Лет пять как минимум у нее есть запаса перед конкурентами.

А так - вполне себе неплохой язычок скала. Мне он нравится существенно больше питона. Да и блох грит, что нечего городить джава-огород. Берите скалу и не жалуйтесь (http://java.dzone.com/articles/effective-java-an-interview-wi) на отсутствие замыканий ;) Единственное сложное место в скале - это имо дженерики. Уж очень они навороченные, а больших туториалов не видно. С другой стороны пока нет нормальной ide - скала не имеет шансов.

Кстати, лист компрехенжнз в JavaFX все-таки вставили...
Вот и думай, что такое хорошо, а что такое плохо ;)

Кстати, лист компрехенжнз в JavaFX все-таки вставили...
Вот и думай, что такое хорошо, а что такое плохо ;)


Я считаю что лист компрехенжнз это хорошо. Проблемма только "what is a good list"? В JavaFX они используют immutable sequence (encapsulated change object or copy on write pattern). В чем-то это хоршо, но в чем-то и плохо одновременно. Я не готов пока делать ставки.

Лист компрехенжнз в Java будет не шибко нужен как самостоятельная сущность, если будут добавлены замыкания по Гафтеру. Имея замыкания, почти всё остальное можно будет написать в библиотеках. О примерах таких библиотек будет мой следующий пост.

Есть такой момент. Имея функциональную базу (замыкания), можно написать любую конструкцию языка. В том же эрланге даже циклов нет: одни функции и рекурсии ;)

Посмотрим. Конечно, замыкания - это большой шаг вперед. Но, в связи с этим появляется новый перл/с++/етс. То есть язык, у которого есть несколько способов блокировки и вообще полтора механизма многопоточности, парочка вариантов работы с вводом-выводом (а добавьте еще и nio2), зачем-то встроенный мехзанизм старого log4j, который не развивается, груз awt.

Теперь добавьте функции, которые могут сделать язык неузнаваемым. Вот программисты от других языков поразвлекаются...

Подход С# мне кажется более стройным и продуманным (непонятно, почему у них нет break с метками).

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

Интересно, что у них из JavaFX выйдет.

большие траты

А кто то говорил что boiler plate все фигня при наличии хороших IDE.... Но с другой стороны если бы был autoboxing функций в Function то уже жить было бы можно...

А кто то говорил что boiler plate все фигня при наличии хороших IDE.... Для большого boiler plate IDE не спасет... То есть, конечно, оно может позволить быстро "написать" кусок кода, но это получается "write once software". Остается проблема readability и maintenability (extensibility и т.п.).



> Для большого boiler plate IDE не спасет...

Так этот "кто-то" ты же и был, две недели назад. Будешь сам с собой спорить? А на самом деле, я полностью с тобой согласен. Java is too verbose, но год от года она лучшается, нужно отдать ей должное...

Кстати, был ли у тебя какой-нибудь шанс поглядеть на Guice?






Так этот "кто-то" ты же и был, две недели назад. Будешь сам с собой спорить? Значит я две недели назад плохо выразил свою мысль, раз был неправильно понят. Наверное я имел в виду, что verbosity языка (типа использования слова public вместо какого-нибудь короткого символа) с лихвой компенсируется современным IDE.

Не путай, пожалуйста, verbosity с boiler plate code. Вот этот код, на псевдо языке, verbose:

iterate variable x in range from 0 to 10 do print string value of x

А вот это boiler plate code, если аналогичный шаблон повторяется в коде снова и снова:

long time = currentTime();
try {
doSomething();
} finally {
recordTime("something", currentTime() - time);
}


Грубо говоря, verbose это когда синтаксические конструкции языка записываются "длинно", а boiler plate это когда над-синтаксические шаблоны повторяются снова и снова. Как и в любом ОО языке, какие-то типы boiler plate кода в Java можно устранить использую ООП (классы, методы). Но некоторые шаблоны кода в текущей версии Java не устранимы (как в примере выше). Для выноса из кода таких шаблонов в первую очередь и нужны замыкания. Это не устранит 100% boiler plate (скорей всего это вообще не достижимая задача), но сделает большее количество таких мест в коде устранимыми.

И конечно, введение closures не сделает Java less verbose. Это позволит иметь less boiler plate code.

"Значит я две недели назад плохо выразил свою мысль, раз был неправильно понят. Наверное я имел в виду, что verbosity языка (типа использования слова public вместо какого-нибудь короткого символа) с лихвой компенсируется современным IDE. "

Cкорее был не правильно понят я, когда заявил тебе именно это (что java too verbose во время нашей беседы.) Кстати, вообще-то стандартное определение verbose включает в себя boiler plate как одну из разновидностей. Например: http://en.wikipedia.org/wiki/Boilerplate_(text)

Ну и вообще понятно что длина ключевых слов имеет очень мало отношения к verbosity языка.


> И конечно, введение closures не сделает Java less
> verbose. Это позволит иметь less boiler plate code.


Если вместо 5 строчек надо будет писать одну -- еще как сделает. ;-)





Если вместо 5 строчек надо будет писать одну -- еще как сделает. ;-) С точки зрения Гафтера (это видно из его доклада) это не основной аргумент в пользу closures. Он доказывает что closures are not just a syntactic sugar, что они увеличивают expressiveness языка в каком-то смысле. Хотя, действительно, как побочный эффект это также во многих местах сильно сократит verbosity :)

Кстати, был ли у тебя какой-нибудь шанс поглядеть на Guice? А сразу после нашего разговора и поглядел. Ну что я могу сказать... yet another injection framework со своими собственными достоинствами (всё в Java коде) и недостатками (код должен зависеть от framework).

Но с другой стороны если бы был autoboxing функций в Function то уже жить было бы можно...

Если я правильно понимаю что вы хотите, то именно это есть в предложенном Гафтером варианте.

  • 1
?

Log in

No account? Create an account