Компания Oracle выпустила (http://www.oracle.com/technetwork/java/index.html) платформу Java SE 8 (http://www.oracle.com/technetwork/java/javase/downloads/inde...) (Java Platform, Standard Edition 8), в качестве эталонной реализации которой используется (http://openjdk.java.net/projects/jdk8/) открытый проект OpenJDK (http://openjdk.org/). В Java SE 8 сохранена полная обратная совместимость с прошлыми выпусками платформы Java, все ранее написанные Java-проекты без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 8 (JDK, JRE и Server JRE) подготовлены (http://www.oracle.com/technetwork/java/javase/downloads/jdk8...) для Linux (x86, x86_64, ARM), Solaris (x86, SPARC), Winodws и OS X. Поддержка Java SE 8 уже интегрирована в такие инструменты для разработчиков, как NetBeans 8.0 (https://netbeans.org/community/releases/80/index.html), IntelliJ IDEA 12 и Oracle JDeveloper.Изначально релиз Java SE 8 планировалось выпустить в сентябре 2013 года, но график разработки был изменён в связи с решением по проведению внеочередной работы по усилению безопасности Java 7, на которую были переброшены многие вовлечённые в разработку Java 8 инженеры. Разработанная в рамках проекта OpenJDK эталонная реализация Java 8 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами. Используя OpenJDK в качестве эталонной реализации сторонние производители могут создавать полностью совместимые с Java SE 8 производные открытые реализации Java. Проприетарный Oracle JDK 8 отличается от OpenJDK наличием некоторых закрытых компонентов, таких как система плагинов, которые не определены в Java-стандарте и не входят в эталонную реализацию Java 8. Oracle JDK поставляются под лицензией BCL (Binary Code Licence).
Основные новшества (http://openjdk.java.net/projects/jdk8/features) Java SE 8:- Интеграция поддержки Lisp-подобных лямбда-выражений ("замыкания"), развиваемых в рамках проекта Lambda (http://openjdk.java.net/projects/lambda). Расширений стандартных библиотек средствами для параллельного выполнения операций над потоками данных, нацеленных на упрощение написания кода для многоядерных процессоров;
- Новый API (http://www.jcp.org/en/jsr/detail?id=310) для работы с датами и временем;
- Поддержка компактных профилей (http://cr.openjdk.java.net/~mr/se/8/java-se-8-edr-spec.html#...) для развёртывания на оборудовании с ограниченными ресурсами приложений, которым не требуются все компоненты платформы;
- Новая система сборки на основе Autoconf;
- Интеграция Nashorn (http://www.opennet.me/opennews/art.shtml?num=35427), легковесного и высокопроизводительного движка JavaScript, работающий поверх виртуальной машины Java (JVM).
URL: http://www.oracle.com/technetwork/java/index.html
Новость: http://www.opennet.me/opennews/art.shtml?num=39334
>Nashorn, легковесного и высокопроизводительного движка JavaScript, работающий поверх виртуальной машины Java (JVM).Ну хоть название честное, без лицемерия и маркетологической чуши:)
Не-а, это ответ на проект Rhino...
Rhino это вроде как-бы кораблики проектировать... При чем тут?
http://www.mozilla.org/rhino/
а что кстати с Rhino не то?
вполне себе производительный, как мне показалось
ну правда для супермегавычислений не использовался, а так нормальное впечатление производит
>>Nashorn, легковесного и высокопроизводительного движка JavaScript, работающий поверх виртуальной машины Java (JVM).
> Ну хоть название честное, без лицемерия и маркетологической чуши:)Это ж вроде с немецкого "носорог"? (а в WoT - ПТ-САУ 6-го уровня :D)
А потом "Боршь" и "Вафля" :)
Опа! Наконец-то нормальную работу с датами и временем сделали, через двадцать лет...
они уже поторопились с календарем - пусть лучше позже, чем шило
> Опа! Наконец-то нормальную работу с датами и временем сделали, через двадцать лет...При желании, нормально работать с датами и временем можно было и раньше,
с помощью отличной "сторонней" библиотеки http://www.joda.org/joda-time/Почти для всех подсистем из "стандартной" Java есть лучшие по качеству альтернативы,
но только в виде "сторонних" библиотек. Например, вместо java.util.logging.*
есть SLF4J+logback, вместо JavaEE - Spring Framework, и т.д. и т.п.
А лямбда это просто синтаксический сахар над анонимными типами или как? я в том плане, что они пермгенобезопасны или нет?
Синтаксический сахар не создает новых классов в рантайме - только компайл. В рантайме инстансы, потому количество лямбд не должно влиять на работу приложения.PS Вроде пермген в HotSpot упразднили.
Синтактический сахар не мейкает новых классов в рантайме - онли компайл. В рантайме инстансы, бикоз коЛЛичество лямбд не должно влиять на ворканье апликации.
дополню ответ выше ссылочкой
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexp...
Написано "Lambda expressions let you express instances of single-method classes more compactly". То есть я понимаю так, что это все же обёртка над анонимными классами.
Хороший релиз. А лямбды народ давно ждал. Наконец-то дождались.
Посмотрел примеры, так и не понял, зачем эта лямбда нужна. Анонимные классы покрывают практически все применение лямбды. А там, где не покрывают, там код становится менее читаемым и труднее отлаживаемым.
> Посмотрел примеры, так и не понял, зачем эта лямбда нужна. Анонимные классы
> покрывают практически все применение лямбды. А там, где не покрывают, там
> код становится менее читаемым и труднее отлаживаемым.А можно тут как-нибудь плюсануть в карму? Согласен на стопиццот.
Жаль, лучше бы еще лет пять потянули - глядишь, и потеснил бы жабу и жаба-машину кто-нибудь...
Когда программисту заняться нечем он или java теснит или с++ хоронит.
Уже двадцатый год теснят и хоронят.
Если> он или java теснит или с++ хоронит
то он не программист
Хоть я уже и на Скале, а всё равно приятно)Кстати, в java8 ещё добавили virtual extensions, т.е. интерфейсы могут иметь дефолтные методы. Например как здесь: http://stackoverflow.com/questions/18198517/java-8-virtual-e...
Вот блин ну зачем! Раньше вместо этого использовались абстрактрые классы и было все четко и разграничего а сейчас будет разброд и шатание а также холивары на тему где лучше в интерфейсе дефолтным методом или в абстрактном классе?И как будет это дело рулиться при наследовании от двух интефейсов с одинаковыми сигнатурами методов и со своими дефолтными (разными) реализациями? Это напоминает мне то, за что я ненавижу С++ - за множественное наследование от классов.
Отвечая на вопрос -- решаться будет так же как в Скале с их mix-in-ами. Определять будет порядок смешивания, который чётко определён.Вдобавок, теперь поведение объекта можно будет смешивать добавляя разные "интерфейсы" (это уже чистый mix-in и слово "интерфейс" тут даже не подходит).
Как-то жидковато для мажорной версии.> Интеграция поддержки Lisp-подобных лямбда-выражений ("замыкания")
сахар, и не более того.
> Увеличение производительности HashMaps в условиях возникновения коллизий;
Пофикшено спустя ~8 лет после обнаружения проблемы. Оперативно.
>Как-то жидковато для мажорной версии.Все знают что новая мажорная версия должна ломать совместимость со старой как у С# или просто? отправлять язык на свалку как Python. Эт изменения, эт, я понимаю.
>>Как-то жидковато для мажорной версии.
> Все знают что новая мажорная версия должна ломать совместимость со старой как
> у С# или просто? отправлять язык на свалку как Python. Эт
> изменения, эт, я понимаю.Насколько я знаю Java с версий 1.1.2 до 7u51 мне не попадались проблемы с обратной совместимостью приложений, написанных для предыдущих версий среды. Обычно всё работает в новой версии JRE и старую можно удалять.
>>>Как-то жидковато для мажорной версии.
>> Все знают что новая мажорная версия должна ломать совместимость со старой как
>> у С# или просто? отправлять язык на свалку как Python. Эт
>> изменения, эт, я понимаю.
> Насколько я знаю Java с версий 1.1.2 до 7u51 мне не попадались
> проблемы с обратной совместимостью приложений, написанных для предыдущих версий среды.
> Обычно всё работает в новой версии JRE и старую можно удалять.Вы - конкретный везунчик. В Java бывает порой даже так, что ABI ломают в минорной версии, ибо в документации одно, а по факту - другое, и правильно как в документации - где-то в районе 1.6 такое было.
Вот именно! Просто подумайте о всех тех несчастных графоманах, которые останутся без средств к существованию, если не смогут продать переиздания своих талмудов "Программирование на <language_name>".
лучше мало, чем совсем ничего
Да и мажорность версий жабы весьма условна, т.к. просто перестали писать "1." в начале.
>В Java SE 8 сохранена полная обратная совместимость с прошлыми выпусками платформы Java, все ранее написанные Java-проекты без изменений будут работоспособны при запуске под управлением новой версии.Вот за это я их уважаю!
Достали уже путать лямбды и замыкания: лямбды - объекты языка, замыкания - прием - программирования.
Во FreeBSD порт OpenJDK8 появился 28 марта: http://www.freshports.org/java/openjdk8/Подкаст "Разбор Полетов", посвящённый JDK 8: http://razbor-poletov.com/2014/04/episode-59.html