Комментарии 92
Друзья, внесу немного оффтопика сейчас, т.к. завтра будет поздно. Сегодня (31 августа) — последний день, когда на Joker 2017 всё еще можно купить билеты по вкусной летней стоимости. До конца дня остались считаные часы. Кто хотел определиться — определяйтесь сейчас.
public interface Отрывать {
AtomicInteger руки = new AtomicInteger(10);
private static void заТакое() {
руки.set(11);
}
}
CompletableFuture<Process> onExit()Я правильно понимаю, что с помощью этой штуки можно сделать процесс-маклауд? :)
www.youtube.com/watch?v=n7itx7O3b_k
Вот почему-то ничего не пишут, закрыли ли они кучу багов и реквестов по JavaFx.
Можно было бы сосредоточиться на платформе и hardcore фичах, типа modularity, а не на языке. Тогда бы и апдейты, глядишь, быстрее выходили.
Тем кто пишет core-либы смириться и жить на старых возможностях языка? Стоит забить на тех, кому нравится java?
Нет, на тех, кому нравится Java, не забить, претензии только к срокам выхода обновлений. Так-то это всё полезные безусловно вещи. Надеюсь, Гёц сотоварищи таки будут продвигать апдейты пошустрее.
Просто те, кому нравится ТОЛЬКО Java, должны понимать, что они вот с такой скоростью будут получать обновления и плюшки. Это, кроме всего прочего, означает, что молодёжь будет изучать другие языки тоже и с бОльшим удовольствием придёт туда, где пишут не только на чистой Java.
Оракл хотел ввести модульность. Но им не дали
Есть договоренность, что если спека всеми принята, то ее делают.
А тут получилось, что люди прямо перед выпуском напрямую отказались от своих слов, посчитав их глупостью.
И дело там не только в «переписывать программы», а в том, что изначальную спеку нужно делать куда масштабней и умней.
Обычная мелкая гражданская война, в которой все правы и неправы одновременно, а страдают вообще другие люди :)
Вот почему-то ничего не пишут, закрыли ли они кучу багов и реквестов по JavaFx
По состоянию на 2016 год (если не читали):
static.rainfocus.com/oracle/oow16/sess/1462485593256001c2xn/ppt/JavaFX%209%20-%20New%20and%20Noteworthy.pdf
(хотя я лично скорблю — хороня флеш уже сколько баянов порвали, а такие вкусные апплеты, имхо с меньшими проблемами безопасности, убили прямо в расцвете их сил)
Но также я наблюдаю развитие языков программирования как платформ. Java, увы, полностью исчезла из интернета, ради которого создавалась, и ушла в глухой сервер-энтерпрайз и мобайл(андроид).
эт божественно
jshell> Map.of("hello", "world")
$3 ==> {hello=world}
Полна боли и страдания жизнь без кортежей и/или классов данных.
Да, поэтому:
1) в конпеляторе есть исследование литералов: http://openjdk.java.net/jeps/186 (это именно исследование, а не финальная спека). Она прям напрямую связана, с обсуждаемой здесь фичей convenience methods (http://openjdk.java.net/jeps/269). Фичу курирует Гёц.
2) уже есть проротипы type values, я писал о них недавно, и буду еще. Фичу курирует Гёц же, и Роуз.
Короче, всё будет, но не мгновенно. Возможно, ускорение релизного цикла, о котором недавно писал Рейнхольт, позволит выкатить подобные mast-have фичи поперед других, более масштабных, изменений, и мы увидим их в ближайшем будущем.
Почему они просто в библиотеку не добавили методы Optional? Зачем ждать новой версии языка?
Это не новая версия языка, это новая версия платформы Java, куда входит и язык, и стандартная библиотека, и тулинг (jshell, например).
Любое изменение SDK должно быть только в мажорных релизах, иначе будет хаос и про существование стабильности можно будет забыть.
И да, ускорение релизного цикла – это было бы очень круто!
Но с планами по развитию платформы, ускорение релизного цикла, это не такой простой шаг. Зарелизить те же Панаму или Валхаллу – это не так просто будет и скорее всего повлечет откладывания релизов на полгода-год.
они на полугодовой цикл переходят
Некоторые фичи обкатываются месяцами перед тем, как попадут в публичный API. Если она не проходит паблик ревью, то ее заворачивают на доработку. Не стоит забывать, что за разработкой и развитием Java/JVM/JDK стоит очень много людей и компаний.
А вот если фича попадает в публичный API, то ее уже оттуда и не вытянуть. Годами будет @deprecated висеть. И что хуже, эту фичу придется поддерживать, чтобы не сломалась и новый функционал нужно делать таким, чтобы не сломал @deprecated :(
А потом программисты начнут использовать эти два метода, а пользователи начнут жаловаться, почему это у них новая версия программы падает с NoSuchMethodError. А программисты им такие, да, теперь вам каждую неделю надо обновлять JRE, чтобы пользоваться нашим софтом.
Я один прочитал как JS hell?
Выглядит и звучит так же, как когда чиновники говорят о прорывах которые в других странах появились уже 10 лет назад.)
Что например мешало добавить удобные методы для создания и манипуляции коллекциями раньше, мне не понятно.
P.S. Понял: вероятно, общие куски кода для default-методов.
приватные методы в интерфейсах
Ребята, пора уже честно признаться — вам очень не хватало
Интерфейсов, Карл! (запах горелого)
А вот без Properties, как в C#, до сих пор грустно. Как хорошо, что есть Lombok, правда, IDE его все так же не понимают…
Потому что это джава, а не хипстерский язык, где каждая новая версия может ломать весь существовавший до этого код.
Java, ну когда в тебе уже появится автовывод типов, ну невозможно смотреть на портянки.
В смысле, JEP-286? :) Когда-нибудь относительно скоро
Это стало возможным благодаря появлению статических методов в интерфейсах (Java 8)
Дефолтных?
public interface HelloWordable {
public static void hello() {
System.out.println("Hello World!");
}
}
public interface Main {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}Или даже вот так:
@SpringBootApplication
@Configuration
public interface TestApplication {
public static void main(String[] args) {
ApplicationContext ctx = SpringApplication.run(TestApplication.class, args);
}
}
А как там дело с модулями?
List.of(1, 2, 3)Неожиданно, что это возвращает неизменяемый List. Типичная ситуация в моём коде — создать List или Map с парой элементов, а потом добавить туда ещё несколько. Через List.of это сфейлится в рантайме с Exception-ом. Думаю, многие проограммисты на этом обожгутся.
Как теперь лучше создавать изменяемые списки, вот так?
new ArrayList(List.of(1, 2, 3))Лучше бы сделали ArrayList.of(1, 2, 3)
С точки зрения всеобщей схемы всего, верной практикой считается использование иммутабельных конструкций. Нужно всячески поощрять разработчиков к иммутабельности, а стиль программирования — к функциональной чистоте.
Если бы существовала мутабельная версия этой конструкции, все говнокодеры мира тут же начали бы ее использовать (не нужно учиться новым вещам, плодить мутабельное всегда проще), а всем остальным пришлось бы смириться с таким положением вещей по причине частоты распространения.
Имхо, именно поэтому, для создания мутабельной версии выбрана специально переусложненная форма. Именно такая как у тебя в примере — использование копирующего конструктора поверх коллекции, полученной через convenience method.
Я не чтобы оракул оракла, это чуть ли не открытым текстом сказано в JEP-269 Convenience Factories.
В дальнейшем эти идеи могут быть развиты с помощью JEP-186 Collection Literals. Предлагается не мусорить с помощью List.of, а сразу писать List list = #[ 1, 2, 3 ];. Но это совершенно отдельный (тоже стратегический) вопрос.
Сборка мусора — это деталь реализации, она никак не связана со спецификацией языка. Один и тот же метод стандартной библиотеки, возвращающий неизменяемую коллекцию, может выполняться на разных JVM с разными сборщиками мусора. Никто вам также не мешает форкнуть OpenJDK и написать свой сборщик мусора. Почему реализация стандартной библиотеки должна оглядываться на сборщики мусора?
Думаю, не будет Collection literals. По крайней мере, не в ближайшие годы.
А если мутабельный список, потокобезопасный он или нет? А добавление в начало или в середину дешёвое или нет? Реализаций списков много. А с Set и Map ещё хуже. Сохраняет ли порядок, сортирует ли ключи. Например, в JavaScript объекты сохраняют порядок вставки, а это дополнительные ненужные накладные расходы в 99% случаев. Сериализуемость, потокобезопасность. Можно ли в Java 9 сериализовать List.of(x) и десериализовать его потом в Java 8, получив аналог Collections.singletonList(x)? Много, много интересных вопросов влечёт такая фича. Это всё на тему того, почему 10 лет назад не сделали.
ArrayList.of(1,2,3) обсуждался, но он перекрывает List.of(1,2,3), а это нехорошо, когда один статический метод перекрывает другой, меняя семантику. Опять же привет старому поспешному дизайнерскому решению, что статический метод можно вызывать, используя подкласс в качестве квалификатора. Напишите вы class MySuperList extends ArrayList implements List, и что будет значить MySuperList.of(1,2,3)?
Готовимся к Java 9. Обзор самых интересных улучшений