LINUX.ORG.RU

Фичи Java 9, которые могут использовать обычные разработчики

 


2

3

Посоны, я вам покушать принес: ссылка

(создайте кто-нибудь тэг «ежедневное java безумие» или как-то так, ибо таких постов будет еще много? Благодаря Тэйлганнеру я еще нескоро смогу)

Короче, Java9 известна тем, что большинство ее фич похоронено внутри компилятора. Там происходят эпические рефакторинги, в рассылочках идут мощнейшие вбросы говна в вентилятор по поводу системы модулей. Но ничего из этого обычный разраб в норме не увидит.

Тут мы набросали несколько вещей, все же доступных для внешнего наблюдения:
- в интерфейсах теперь можно не просто делать методы, не только статические, но еще и приватные! Авторы воспросов для собеседования «чем абстрактный класс отличается от интерфейса» бьются в истерике
- auto closable переменные в try-with-resources можно объявлять не только внутри try, а где угодно, если они effectively final
- List.of(1, 2, 3); реализация выбирается в зависимости от параметров
- IntStream.range(1, 10).dropWhile(x -> x < 5).forEach(System.out::println)
- Optional.empty().or(() -> Optional.of(«LOR уже не торт»))
- Optional.of(1).stream().map(x -> x * 3); такая мапа будет ленивой
- Optional.empty().ifPresentOrElse(x -> System.out.println(x), () -> System.out.println(«empty»));
- CompletableFuture.clone(); завершение клона не завершает родителя, завершения родителя завершает все слоны
- completableFuture.completeOnTimeout(«нифига, в жабе изобрели таймауты!», 1, TimeUnit.SECONDS)
- StackWalker может бегать по стектрейсам без создания Exception
- нижнее подчеркивание больше нельзя юзать как идентификатор

jshell> ProcessHandle current = ProcessHandle.current();
current ==> 6349

jshell> current.pid()
$33 ==> 6349

jshell> current.info().\TAB
arguments()          command()            commandLine()        equals(              getClass()
hashCode()           notify()             notifyAll()          startInstant()       toString()
totalCpuDuration()   user()               wait(

jshell> current.info().command()
$34 ==> Optional[/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java]

Как всегда, нужно/ненужно, будете ли вы лепить всё на интерфейсах, и так далее? =)

Перемещено leave из talks

★★★★☆

Ответ на: комментарий от Bahamut

Делая последний ненужнее и ненужнее.

foror ★★★★★
()
Ответ на: комментарий от Bahamut

В джаву спустя десять лет начали подвозить C#?

Java же была «halfway to Lisp». Теперь пора делать 3/4 way to Lisp. Потихоньку, медленно, специально для дебилов.

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

anonymous
()
Ответ на: комментарий от e1nste1n

Конечно. Смотри, в моём посте буква «o» подчёркнута.

EXL ★★★★★
()

CompletableFuture.clone();

Должно быть copy(), там семантика совсем не тупого clone

grossws
()
Ответ на: комментарий от Legioner

Нифига не понял, но это try мне в принципе не понравилось. Ну да ладно, пусть будет.

Видимо, всё ещё на 7 не переехал, если о try-with-resources не в курсе. Одна из killer features, собственно, 7.

Да вроде его несложно было создавать, сомнительное улучшение, ну да ладно.

Сделать new Exception() не сложно, но дорого. Особенно, когда нафиг не нужен весь стек.

grossws
()

Авторы воспросов для собеседования «чем абстрактный класс отличается от интерфейса» бьются в истерике

Почему?

WereFox ★☆
()
Ответ на: комментарий от WereFox

видно потому что отличали абстрактный класс от интерфейса только наличием приватных методов же

Мне кстати не хватало в свое время протектед методов в интерфейсах

Deleted
()
Ответ на: комментарий от Deleted

видно потому что отличали абстрактный класс от интерфейса только наличием приватных методов же

То есть то, что в интерфейсе содержатся только объявления методов, но не их реализация - это типа пофигу?

WereFox ★☆
()
Ответ на: комментарий от WereFox

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

Deleted
()
Ответ на: комментарий от Deleted

а тем что один класс может наследоваться от одного класса, но может имплементировать много интерфейсов не отличали?

qnikst ★★★★★
()
Ответ на: комментарий от Deleted

Тут хочется что-то типа protected, чтобы не выставлять методы, необходимые для реализации trait/mixin в виде public.

grossws
()
Ответ на: комментарий от grossws

Видимо, всё ещё на 7 не переехал, если о try-with-resources не в курсе.

Я в курсе, но мне не нравится, как оно сделано.

Одна из killer features, собственно, 7.

Довольно бесполезная фича.

Да вроде его несложно было создавать, сомнительное улучшение, ну да ладно.

Сделать new Exception() не сложно, но дорого. Особенно, когда нафиг не нужен весь стек.

Ты уверен, что эта альтернатива не будет делать ровно то же самое ровно с теми же затратами?

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Ты уверен, что эта альтернатива не будет делать ровно то же самое ровно с теми же затратами?

Эту тему даже на конфах мусолят, но «ведущие»™ специалисты вроде тебя, один фиг в танке.

Deleted
()
Ответ на: комментарий от Legioner

Я в курсе, но мне не нравится, как оно сделано.

о, а у тебя есть предложения лучше? опили, пожалуйста

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Самый простой вариант — сделать через лямбды 8-ки, как в Kotlin:

use(new FileInputStream(bla), stream -> {
});

или

new FileInputStream(bla).use(stream -> {
});

Хотя в принципе совсем простой вариант — вообще не делать эту конструкцию, try-finally прекрасно справлялся со своей задачей. Лучше бы его проапгрейдили.

Собственно не нравятся 2 вещи: во-первых объявление переменной внутри try выглядит совсем не по-джавовски, почему я тогда внутри if не могу объявить переменную? Ну ладно, внутри for могу, но всё равно сколько я ни пишу этот try, не могу к нему привыкнуть, некрасиво он выглядит. Во-вторых suppressed исключения не добавляются при исключениях из finally, например. В итоге да, в текущем виде try-with-resources лучше, т.к. правильней обрабатывает исключения при закрытии ресурса, но это проблема finally а не заслуга try-with-resources.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

1- когда эту фичу пилили, никаких лямбд не было, а анонимный иннеркласс писать люто неудобно (особенно если у тебя не навороченная IDE)

2 - оба твоих варианта сейчас не покрывают очень частый способ исползования: в try блоке много auto closable переменных, и они могут быть связаны между собой (например, в конструктор output stream передаются какие-то поля из там же созданного input stream или что-то такое). Именно поэтому там используется блок.

попробуй отрефакторить свою запись и починить эти проблемы (хотя бы вторую)?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

1- когда эту фичу пилили, никаких лямбд не было, а анонимный иннеркласс писать люто неудобно (особенно если у тебя не навороченная IDE)

В планах были. Можно было бы отложить.

2 - оба твоих варианта сейчас не покрывают очень частый способ исползования: в try блоке много auto closable переменных, и они могут быть связаны между собой (например, в конструктор output stream передаются какие-то поля из там же созданного input stream или что-то такое). Именно поэтому там используется блок.

Тут есть два варианта — либо вкладывать скоупы, либо сделать другую библиотечную функцию. Например такую:

withResources(resources -> {
    InputStream fileStream = resources.add(new FileInputStream("bla"));
    Reader reader = resources.add(new InputStreamReader(fileStream));
});
И, кстати, у этого варианта есть одно важное преимущество, он динамический. Если, например, у тебя есть файл, который либо файл, либо загзипован и тебе надо в зависимости от условия либо его открыть, либо сначала распаковать через GzipInputStream, а потом использовать, но в итоге использование сводится к одинаковому использовать низлежащего InputStream, то у тебя получается динамический выбор, который через try-with-resources не сделать, приходится городить кучу лишнего.

попробуй отрефакторить свою запись и починить эти проблемы (хотя бы вторую)?

Вообще говоря самый простой способ починить — свести всё к одному варианту:

new InputStreamReader(new FileInputStream("file"), UTF_8) конструктор InputStreamReader-а исключение практически гарантированно не бросит (OutOfMemory разве что, но шансы этого стремятся к нулю, да и OOM это так себе ситуация, там и close может сломаться). Закрытие его закроет и низлежащий поток. И все стандартные обёртки потоков себя так ведут. Поэтому какой-то насущной необходимости во множестве переменных нет. Иногда будет лишний отступ, ну и ладно.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Можно было бы отложить.

отложить на три года?

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

кстати, Рейнхольт как раз недавно писал, что нужно сократить релизный цикл жабы до 1-2 лет, причем следовать строго по графику (если релиз запланирован на дату X, он выйдет на дату X, даже если в него попадут не все фичи, или текущая реализация не полна)

new InputStreamReader(new FileInputStream(«file»), UTF_8)

а если ты обрабатываешь не 1 «корневой» стрим, а 5? :)))

stevejobs ★★★★☆
() автор топика

> нижнее подчеркивание

Знак подчёркивания

ZenitharChampion ★★★★★
()
Ответ на: комментарий от stevejobs

нужно сократить релизный цикл жабы до 1-2 лет

Сократили до 6 месяцев, десятка через полгода, после релиза девятки.

foror ★★★★★
()
Ответ на: комментарий от foror

Что-то действительно какой-то PHP получается.

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

Надо на Аду сваливать.

anonymous
()
Ответ на: комментарий от anonymous

Ничего не поменяется, просто то, что раньше лежало мертвым грузом, готовое по 3 года (типа List.of) будет выпущено за полгода. Ну и видимо есть пласт «новых» более-менее проработанных фич, которые можно релизить в следующие несколько лет.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.