Если есть уверенность, что уже ничего не поломают, почему бы и нет.

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

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

Какие риски, там же совместимость в обратную сторону.

JDK 8 делается в концепции Test-driven development. Так что сырой код, который не проходит необходимых тестов и ломает существующую совместимость, в голове репозитория разработки (mercurial) не публикуется.

Новые возможности, которые заявлены в окончательном варианте JDK, могут быть изменены, могут поменять API и т.д..

Совместимость это конечно хорошо, но например при выходе семерки были глюки с работой lucene на ней. Что-то там ломали сильно внутри.

А расскажи, какие конкретно фичи использовал? Лямбды само собой, а ещё?

Я тоже присматриваюсь к восьмёрке, но, честно, переводить на неё продакшен пока ссу. Проект mission critical. Полагаю, надо следить за рассылками/форумами/етц, ловить момент, когда наступит feature freeze. Т.е. после этого момента будет только вылизывание существующих фич, но не добавление/удаление/изменение существующих. Вот тогда и переползать.

А расскажи, какие конкретно фичи использовал? Лямбды само собой, а ещё?

Stream api в коллекциях, все эти forEach filter map collect etc. Имхо очень удобно, то чего в яве всегда не хватало. Код практически без циклов смотрится забавно.

Еще Optional с его orElseGet и orElseThrow и default методы в интерфейсах.

В принципе посмотрел на новый data time api, хорошо сделали, можно будет joda time из зависимостей выкинуть.

Я тоже присматриваюсь к восьмёрке, но, честно, переводить на неё продакшен пока ссу. Проект mission critical.

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

JDK 8 Features

http://openjdk.java.net/projects/jdk8/features

Stream api в коллекциях, все эти forEach filter map collect etc. Имхо очень удобно, то чего в яве всегда не хватало. Код практически без циклов смотрится забавно.

Еще Optional с его orElseGet и orElseThrow и default методы в интерфейсах.

В принципе посмотрел на новый data time api, хорошо сделали, можно будет joda time из зависимостей выкинуть.

Спасибо, круто. Я тоже буду новый проект начинать на 8-ке, пожалуй. Там разработки на полгода точно.

Тут же вопрос в том, что проект только весной в марте-апреле в тестовую эксплуатацию пойдет. И к этому моменту они релиз явно успеют сделать.

Удачи тогда :)

И к этому моменту они релиз явно успеют сделать.

Если вы про Java - то они столько раз уже откладывали... Я бы не стал так надеяться.

А чем плоха система типов в скалке? Какие заморочки?

А чем плоха система типов в скалке? Какие заморочки?

Неосиляторство же.

А чем плоха система типов в скалке? Какие заморочки?

Переусложнена. Т.е. вкуривается конечно, но мне прям страшно представить как с ней будет разбираться программер, не тянущий на senior.

Плюс не очень хорошо совместима с явовской, что порождает проблемы совместимости с некоторыми ее библиотеками. И переполненность кода тяжелой артиллерией в виде asInstanceOf[T]

Ну я не тяну на senior, зато систему типов скалки вроде как освоил. Хотя тонкости в уме не держу, подзабыл немного все эти T+ и T-, но при желании, думаю, память освежить не проблема.

А asInstanceOf[T] не нужен же! Есть же pattern matching!

Доводилось мне видеть код одного неосилятора скалки, переполненный этой «тяжёлой артиллерией». Нельзя таких пускать код писать.

Ну я не тяну на senior, зато систему типов скалки вроде как освоил. Хотя тонкости в уме не держу, подзабыл немного все эти T+ и T-, но при желании, думаю, память освежить не проблема.

Ну вот в том то и проблема, что корректное использование всех этого хозяйства с ковариантностями, контрвариантностями, upper|lower|view bounds и прочими тонкостями практически невозможно постоянно держать в голове.

Доводилось мне видеть код одного неосилятора скалки, переполненный этой «тяжёлой артиллерией». Нельзя таких пускать код писать.

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

они столько раз уже откладывали

Кажется, что они это сделали всего один раз. ;)