Pull to refresh

Comments 25

UFO just landed and posted this here
Не просто не обновили, там всё ещё предлагают Java 8.
Вы еще попросите обновить в установищике надпись «3 Billion Devices Run Java».
Надо по случаю праздника запускать Epsilon GC, пусть память льётся рекой, как шампанское!
>> JEP 335: Deprecate the Nashorn JavaScript Engine

а дальше что, какой движок следующий?
«карусель», конечно, получается — не успели отказаться от Rhino, уже и Nashorn выкидывают.
(имхо, последнего не жалко: я так и не нашел у Nashorn штатного api для программного контроля и отладки скриптов. а вот с Rhino получилось нарисовать собственный отладчик скриптов в нашем окружении. )

но, все-таки — кто в курсе вопроса? ждем возвращения Rhino или будут скрещивать ужа с ежом в формате java+v8?

Если хотите оставить этот движок, можете стать его мейнтейнером:
>An alternative is for a set of credible developers to express a clear desire to maintain Nashorn going forward

А так да, GraalVM уже покрывает одним выстрелом не только js.
Мда, у меня в проекте на бекенде часть логики как раз через JS была реализована и работала под Nashorn. Сложно ли перейти будет на GraalVM?
Graal.js — это не drop in replacement для Nashorn, это отдельный продукт. API в целом совместимое, но есть шероховатости. Нужно будет вручную все проверять.

Хоть и LTS, но с точки зрения фич релиз абсолютно проходной. Тут больше антифич, когда что-то выкосили. Ноль изменений в Stream API. Гениальный метод isEmpty в Optional.

На словах «гениальный метод» вспомнилось, как они добавили «оператор Элвиса»…
В чём сложность наконец-то его реализовать в синтаксисе? Не понимаю. Методы в Objects добавлять (аля Objects.requireNonNullElse), какое-то ну такое… нововведение.
Странное противопоставление «хоть и LTS, но с точки зрения фич проходной». По-моему, LTS с точки зрения фич как раз и должен быть проходным: он про стабильность, поэтому все крупные фичи лучше в других версиях вносить, чтобы в случае чего до LTS успеть поправить.
Ну LTS-релизики ведь изначально предполагаются консервативными и стабилизирующими. Выкинули что не нужно и не стали добавлять то, что могут выкинуть
У меня на работе проект завязан на IBM OS/400. Последняя версия JVM доступная для нас Java8. IBM выпустили пресс-релиз о том что следующим поддевживаемым релизом для нас будет Java11. Сроков когда он станет доступным так никто и не дал. Некоторые сотрудники шутят о том что к Java12-13 мы обновимся на 11. И судя по их неспешности и реактивности, нам так и прийдётся проскакивать 2-3 релиза до следующего LTS.

Это конечно хорошо, что они почистят старый код, хотя и немного непривычно после долгих лет обратной совместимости.

У меня вопрос лицензия java11 уже позволяет её использовать в коммерческих целях?
Всё в порядке с лицензией. Достаточно не использовать сборку от Oracle.

Хочу уточнить, что LTS он ТОЛЬКО для тех, кто купит лицензию. Все остальные переводятся в ряды бесплатных тестировщиков.

UFO just landed and posted this here

Из хоть как-то значимого для разработчиков бизнес-логики (не перформанс-инженеров) по сути появились 2 фичи:
1) JEP 330: Launch Single-File Source-Code Programs.
Суть: если файл с исходниками на Java не ссылается ни на какие другие файлы с исходниками, т.е. является SFSCP (Single File Source-Code Program), например:


// java HelloWorld.java
public class HelloWorld {
    public static void main(String[] args){
        System.out.println("Hello World!!!");
    }
}

, то запустить его теперь можно просто так:


java HelloWorld.java

2) JEP 323: Local-Variable Syntax for Lambda Parameters (var`ы в лямбда-параметрах).
Суть — в лямбдах теперь перед параметрами можно поставить ключевое слово var. И тип тогда сам выведится. Какую проблему это решает, спросите вы? Ведь в лямбдах и раньше можно было не писать тип вовсе и он итак прекрасно выводился… На самом деле проблема в том, что иногда нужно аннотировать типы (фича появилась в Java 8) в лямбдах — и раньше для этого приходилось явно прописывать тип, а теперь можно вместо этого их выводить — поставить вместо типа var — и тип выведется из контекста, но теперь перед ним можно поставить аннотацию. Раньше было нельзя.
Это можно использовать в tools`ах типа CheckerFramework`а и доп. проверок в IDE — например, аннотаций типа NotNull и Nullable, предоставляющих такую фичу, как nullability в Java (не Kotlin, конечно, но лучше, чем ничего).

Sign up to leave a comment.