company_banner

Пришло время Java 12! Обзор горячих JEP-ов


    Прошло полгода, а значит — время устанавливать новую Java! Это был долгий путь, и до конца добрались немногие. Из интересных JEP-ов отвалились сырые строки, а вот об оставшемся мы поговорим под катом.


    Как всё происходит


    Выпуск новой версии Java проходит согласно новому «ускоренному» релизному циклу длиной примерно в полгода. Точные даты определены на странице проекта. Для JDK 12 существовало несколько основных фаз:


    • 2018/12/13 — Первая фаза замедления (в этот момент делается форк от основной ветки в репозитории);
    • 2019/01/17 — Вторая фаза замедления (завершить всё, что только можно);
    • 2019/02/07 — Релиз-кандидат (фиксятся только самые важные баги);
    • 2019/03/19 — Релиз, General Availability. < — вы находитесь здесь

    Что нам с этого расписания? Да в сущности, ничего — мы только что пришли к финишу, и барски взираем на любителей легаси с высоты новенькой свеженькой JDK 12.


    Баги! Паника! Все на дно!



    Когда выходит новая не-LTS версия, обычно всем глубоко наплевать на новые фичи. Интересней, не развалится ли всё к морским чертям.


    Конечно, баги есть, много, но не в JDK 12 :) Судя по джире — всё в норме:



    Процитирую запрос, чтобы вы в точности понимали, что такое «норма»:


    project = JDK AND issuetype = Bug AND status in (Open, "In Progress", New) AND priority in (P1) AND (fixVersion in (12) OR fixVersion is EMPTY AND affectedVersion in (12) AND affectedVersion not in regexVersion("11.*", "10.*", "9.*", "8.*", "7.*", "6.*")) AND (labels is EMPTY OR labels not in (jdk12-defer-request, noreg-demo, noreg-doc, noreg-self)) AND (component not in (docs, globalization, infrastructure) OR component = infrastructure AND subcomponent = build) AND reporter != "Shadow Bug" ORDER BY priority, component, subcomponent, assignee

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


    Более формально общение с багами задекларировано в специальном документе, JEP 3: JDK Release Process, владельцем которого является наш бессмертный стюард по неспокойным волнам Java-океана — Марк Рейнхольд.


    И в особенности стоит докопаться абзаца, рассказывающего, кто виноват и что делать, как переносить тикеты, если к 12 релизу уже не успеть. Надо поставить в багтрекере метку jdk$N-defer-request в которой N указывает, с какого именно релиза хочется перенести, и оставить комментарий, первая строка которого — Deferral Request. Дальше за ревью всех таких запросов берутся лиды соответствующих областей и проектов.


    Проблемы прохождения TCK нельзя проигнорировать подобным образом — гарантируется, что Java остаётся Java, а не чем-то жабообразным. Метка jdk$N-defer-request label никуда не исчезает. Интересно, что они делают с людьми, которые нарушают правило неудаления метки — предлагаю скормить морским свинкам.


    Тем не менее, таким образом можно посмотреть, сколько багов перенесено на JDK 13. Попробуем такой запрос:


    project = JDK AND issuetype = Bug AND status in (Open, "In Progress", New) AND (labels in (jdk12-defer-request) AND labels not in (noreg-demo, noreg-doc, noreg-self)) AND (component not in (docs, globalization, infrastructure) OR component = infrastructure AND subcomponent = build) AND reporter != "Shadow Bug" ORDER BY priority, component, subcomponent, assignee

    Всего 1 штука, JDK-8216039: «TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange». Негусто. Если этот довод всё ещё не помог, то, как ваш адвокат, рекомендую попробовать успокоительное.


    И что же в сухом остатке?



    Ясно, что большинство фичей затрагивает не пользователей (Java-программистов), а разработчиков самого OpenJDK. Поэтому я на всякий случай делю фичи на внешние и внутренние. Внутренние можно пропустить, но я обижусь, столько текста написал.


    189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)


    Внешняя фича. Вкратце, люди не любят, когда Java тормозит, особенно если SLA требует отзывчивости порядка 10-500 миллисекунд. Теперь у нас есть бесплатный низкопаузный GC, который пытается работать ближе к левому краю этого диапазона. Компромисс таков, что мы обмениваем CPU и RAM на уменьшение задержек. Фазы маркировки и уплотнения хипа работают параллельно с живыми тредами приложения. Оставшиеся небольшие паузы связаны с тем, что всё равно надо искать и обновлять корни графа объектов.


    Если ничего из сказанного не имеет для вас никакого смысла — не беда, Shenandoah просто работает, вне зависимости от понимания или непонимания глубинных процессов.


    Работают над ним Алексей Шипилёв, Кристина Флад и Роман Кеннке — нужно сильно постараться, чтобы не знать об этих людях. Если вы в целом понимаете, как работают GC но не представляете, чем там может заниматься разработчик — рекомендую взглянуть на хаброперевод чудесной Лёшиной статьи «Самодельный сборщик мусора для OpenJDK» или на серию JVM Anatomy Quarks. Это очень интересно.


    Экстремально важно. Oracle решили не поставлять Sheandoah ни с какой из своих релизных сборок — ни с той, что на jdk.java.net, ни с той, которая на oracle.com. Учитывая, что Shenandoah — одна из важнейших фичей JDK 12, стоит установить какую-то другую официальную сборку, например, от Azul.



    230: Microbenchmark Suite


    Внутренняя фича. Если вы хоть раз пытались писать микробенчмарки, то знаете, что это делается на JMH. JMH — это фреймворк для создания, сборки, запуска и анализа микробенчмарков для Java и других JVM-языков, написанный сами понимаете кем (все совпадения случайны). К сожалению, не всё, что делается в мире "нормальных" приложений можно применить внутри JDK. Например, вряд ли мы когда-то увидим там нормальный код на Spring Framework.


    К счастью, начиная с 12 версии можно использовать хотя бы JMH, и уже есть набор тестов, которые на нём написаны. Посмотреть можно в jdk/jdk/test/micro/org/openjdk/bench (можете в браузере прямо посмотреть, этот путь — ссылка).


    Например, вот как выглядит тест на GC.


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

    @BenchmarkMode(Mode.AverageTime)
    @OutputTimeUnit(TimeUnit.NANOSECONDS)
    @State(Scope.Thread)
    public class Alloc {
    
        public static final int LENGTH = 400;
        public static final int ARR_LEN = 100;
        public int largeLen = 100;
        public int smalllen = 6;
    
        @Benchmark
        public void testLargeConstArray(Blackhole bh) throws Exception {
            int localArrlen = ARR_LEN;
            for (int i = 0; i < LENGTH; i++) {
                Object[] tmp = new Object[localArrlen];
                bh.consume(tmp);
            }
        }
    
        //...
    }



    325: Switch Expressions (Preview)


    Внешняя фича. Коренным способом изменит ваш подход к написанию бесконечных свичей длиной более двух экранов. Глядите:


    Virgin Java Switch vs ...


    int dayNum = -1;
    switch (day) {
        case MONDAY:
        case FRIDAY:
        case SUNDAY:
            dayNum = 6;
            break;
        case TUESDAY:
            dayNum = 7;
            break;
        case THURSDAY:
        case SATURDAY:
            dayNum = 8;
            break;
        case WEDNESDAY:
            dayNum = 9;
            break;
    }

    Почему плохо: много букв, можно пропустить break (особенно, если ты наркоман, или болеешь СДВГ).


    … vs Chad Java Swtich Expression!


    int dayNum = switch (day) {
        case MONDAY  -> 0;
        case TUESDAY -> 1;
        default      -> {
            int k = day.toString().length();
            int result = f(k);
            break result;
        }
    };

    Почему хорошо: мало букв, безопасно, удобно, новая клёвая фича.


    Бонус: если ты садист, то тебе доставит глубочайшее удовлетворение, как тысячи разработчиков IDE теперь мучаются с поддержкой этой фичи. Да, lany, да? Его можно поймать после доклада 6-ого апреля и мягко попросить выдать все грязные подробности.


    Это preview фича, просто так она не заработает! При компиляции, в javac нужно передать опции командной строки --enable-preview --release 12, а для запуска через java — один только флаг --enable-preview.



    334: JVM Constants API


    Внутренняя фича. Разработчикам хочется манипулировать классфайлами. Нужно делать это удобно, и это постановка задачи. По крайней мере, так сказал Брайан Гёц, который владеет этим JEP-ом :-) Всё это часть более масштабного поля брани, но пока не будем углубляться.


    В каждом Java-классе есть так называемый "константный пул", где находится свалка либо каких-то значений (вроде стрингов и интов), или рантаймовые сущности вроде классов и методов. Порыться в этой свалке можно с помощью инструкции ldc — "load costant", поэтому всё это барахло называется loadable constants. Есть ещё специальный случай для invokedynamic, но неважно.


    Если мы работаем с классфайлами, то хотим удобно моделировать байткодные инструции, и следовательно — loadable constants. Первое желание — просто наделать соответствующих Java-типов, но как представить им "живой" класс, структуру CONSTANT_Class_info? Class-объекты зависят от корректности и консистентности загрузки классов, а с загрузкой классов в Java творится адовая вакханалия. Начнём с того, что не все классы можно загрузить в VM, а описывать-то их всё равно надо!


    Хотелось бы как-то попроще управлять вещами вроде классов, методов и менее известными зверьми вроде method handles и динамических констант, с учётом всех этих тонкостей.


    Это решается введением новых value-based типов символических ссылок (в смысле JVMS 5.1), каждая из которых описывает какой-то конкретный вид констант. Описывает чисто номинально, в отрыве от загрузки классов или вопросов доступа. Они живут в пакетах вроде java.lang.invoke.constant и есть не просят, а на сам патч можно взглянуть здесь.



    340: One AArch64 Port, Not Two
    Внешняя фича. Уже в JDK 9 сложилась странная ситуация, когда Oracle и Red Hat одновременно поставили на боевое дежурство свои ARM-порты. И вот мы видим конец истории: 64-битную часть оракловского порта убрали из апстрима.


    Можно было бы долго копаться в истории самому, но есть способ лучше. В разработке этого JEP поучаствовала компания BellSoft, а её офис расположен в Питере, рядом с бывшим офисом компании Oracle.


    Поэтому я сразу обратилился сразу к Алексею Войтылову, CTO компании BellSoft:


    "BellSoft выпускает Liberica JDK, которая, помимо x86 Linux/Windows/Mac и Solaris/SPARC, поддерживает и ARM. Начиная с JDK 9 для ARM мы сфокусировались на улучшении производительности порта AARCH64 для серверных применений и продолжили поддерживать 32-битную часть ARM порта для встраиваемых решений. Таким образом на момент выхода JDK 11 сложилась ситуация, когда 64-битную часть порта от Oracle никто не поддерживал (включая Oracle), и OpenJDK сообщество приняло решение удалить ее, чтобы сфокусироваться на AARCH64 порте. На настоящий момент он более производительный (см, например, JEP 315, который мы заинтегрировали в JDK 11) и, начиная с JDK 12, поддерживает все фичи, присутствовавшие в порте от Oracle (последнюю, Minimal VM, я заинтегрировал в сентябре). Поэтому в JDK 12 я с удовольствием помог Bob Vandette удалить этот рудимент. В итоге OpenJDK сообщество получило один порт на AARCH64 и один порт ARM32, что, безусловно, облегчает их поддержку."



    341: Default CDS Archives


    Внутренняя фича. Проблема в том, что при старте Java-приложения загружаются тысячи классов, отчего создаётся ощущение, что Java ощутимо тормозит при старте. Да кому тут врать, это не просто "ощущение" — так оно и есть. Чтобы исправить проблему издревле практикуются различные ритуалы.


    Class Data Sharing — это фича, пришедшая к нам из глубины веков, как коммерческая фича из JDK 8 Update 40. Она позволяет упаковать весь этот стартапный мусор в архив какого-то своего формата (вам не нужно знать — какого), после чего скорость запуска приложений возрастает. А через некоторое время появился JEP 310: Application Class-Data Sharing, который позволил обходиться таким же образом не только с системными классами, но и классами приложений.


    Для классов JDK это выглядит так. Вначале мы дампим классы командой java -Xshare:dump, и потом запускаем приложение, сказав ему использовать этот кэш: java -Xshare:on -jar app.jar. Всё, стартап немного улучшился. Вот вы знали об этой фиче? Много кто не знает до сих пор!


    Здесь выглядит странно вот что: зачем каждый раз самостоятельно ритуально писать -Xshare:dump, если дефолтный результат выполнения этой команды немножко предсказуем ещё на этапе создания дистрибутива JDK? Согласно документации, если дистрибутив Java 8 устанавливался с помощью инсталлятора, то прямо в момент установки он должен запускать нужные команды за тебя. Типа, инсталлятор тихонечко майнит в уголке. Но зачем? И что делать с дистрибутивом, который распространяется не в виде инсталлятора, а как зипник?


    Всё просто: начиная с JDK 12 архив CDS будет генериться создателями дистрибутива, сразу же после линковки. Даже для ночных билдов (при условии что они 64-битные и нативные, не для кросс-компиляции).


    Пользователям даже не нужно знать о наличии этой фичи, потому что, начиная с JDK 11, -Xshare:auto включена по-умолчанию, и такой архив подхватится автомагически. Таким образом, просто сам факт обновления на JDK 12 ускоряет запуск приложения!



    344: Abortable Mixed Collections for G1


    Внутренняя фича. Честно говоря, я ничего не понимаю в работе G1 объяснение фичей GC дело неблагодарное, т.к. требует понимания деталей его работы и от объясняющего, и от понимающего. Для большинства же людей, GC — это какой-то чёртик из табакерки, которому можно накрутить в случае чего. Поэтому проблему надо объяснить как-то попроще.


    Проблема: G1 мог бы работать и получше.


    Ладно, проблема в том, что GC — это компромисс множества параметров, один из которых — продолжительность паузы. Иногда пауза оказывается слишком долгой, и тогда неплохо иметь возможность её отменить.


    Когда такое происходит? G1 действительно анализирует поведение приложения и выбирает фронт работ (выраженный в виде collection set) на основе своих умозаключений. Когда объем работ утверждён, G1 берётся собрать все живые объекты в collection set, упрямо и без остановок, за один присест. Иногда это занимает излишне много времени. По сути, это означает, что G1 неправильно посчитал объем работ. Его можно обдурить, внезапно поменяв поведение своего приложения так, что эвристика будет отрабатывать поверх протухших данных, когда в collection set попадет слишком много старых регионов.


    Чтобы выйти из положения, G1 был доработан следующим механизмом: если эвристика регулярно выбирает неверный объем работ, G1 переходит на инкрементальную сборку мусора, шаг за шагом, и каждый следующий шаг (если он не влез в целевое время выполнения) можно отменить. Кое-что инкрементально собирать не имеет смысла (молодые регионы), поэтому вся такая работа выделяется в "обязательный" блок, который таки выполняется непрерывно.


    Что с этим делать конечному пользователю? Ничего, нужно обновиться на JDK 12, всё станет лучше само собой.



    346: Promptly Return Unused Committed Memory from G1


    Внутренняя фича. Проблема в том, что если у нас есть большой хип, который никто активно не использует, кажется справедливым получить всю эту неактивную память назад в операционную систему. До JDK 12 этого, впрочем, не происходило.


    Чтобы достигнуть своей цели по допустимой длине паузы, G1 производит набор инкрементальных, параллельных и многоэтапных циклов. В JDK 11 он отдаёт commited-память операционной системе только при full GC, или в ходе фазы параллельной маркировки. Если подключить логирование (-Xloggc:/home/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps), то эта фаза отображается как-то так:


    8801.974: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 12582912000 bytes, allocation request: 0 bytes, threshold: 12562779330 bytes (45.00 %), source: end of GC]
    8804.670: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested]
    8805.612: [GC concurrent-mark-start]
    8820.483: [GC concurrent-mark-end, 14.8711620 secs]

    Забавно то, что G1 как может борется с полными остановками, да и concurrent cycle запускает только при частых аллокациях и забитом хипе. Наша ситуация, когда хип никто не трогает — это нечто прямо противоположное. Ситуации, когда G1 почешется отдать память в операционную систему будут происходить ну очень редко!


    Так бы все и забили на эту проблему ("купи ещё больше оперативки, чего как нищеброд!"), если бы не одно но — есть всякие облака и контейнеры, в которых это означает недостаточную утилизацию и потерю серьезных денег. Глядите, какой крутой доклад, до краёв наполненный болью.


    Решением стало научить G1 хорошо вести себя в этом конкретном случае, как уже умеют Шенанда или GenCon из OpenJ9. Нужно определять недостаточную утилизацию хипа и соответственно уменьшать его использование. На каких-то тестах на Томкате это позволило уменьшить расход памяти почти в два раза.


    Суть в том, что приложение считается неактивным, или если истёк интервал (в миллисекундах) с последней сборки и нет concurrent cycle, или если getloadavg() на периоде в одну минуту показал нагрузку ниже определённого порога. Как только что-то из этого произошло, запускается периодическая сборка мусора — она конечно, не почистит настолько же хорошо, как полная сборка, зато минимально затронет приложение.


    Можно повтыкать вот в этот лог:


    (1) [6.084s][debug][gc,periodic ] Checking for periodic GC.
        [6.086s][info ][gc          ] GC(13) Pause Young (Concurrent Start) (G1 Periodic Collection) 37M->36M(78M) 1.786ms
    (2) [9.087s][debug][gc,periodic ] Checking for periodic GC.
        [9.088s][info ][gc          ] GC(15) Pause Young (Prepare Mixed) (G1 Periodic Collection) 9M->9M(32M) 0.722ms
    (3) [12.089s][debug][gc,periodic ] Checking for periodic GC.
        [12.091s][info ][gc          ] GC(16) Pause Young (Mixed) (G1 Periodic Collection) 9M->5M(32M) 1.776ms
    (4) [15.092s][debug][gc,periodic ] Checking for periodic GC.
        [15.097s][info ][gc          ] GC(17) Pause Young (Mixed) (G1 Periodic Collection) 5M->1M(32M) 4.142ms
    (5) [18.098s][debug][gc,periodic ] Checking for periodic GC.
        [18.100s][info ][gc          ] GC(18) Pause Young (Concurrent Start) (G1 Periodic Collection) 1M->1M(32M) 1.685ms
    (6) [21.101s][debug][gc,periodic ] Checking for periodic GC.
        [21.102s][info ][gc          ] GC(20) Pause Young (Concurrent Start) (G1 Periodic Collection) 1M->1M(32M) 0.868ms
    (7) [24.104s][debug][gc,periodic ] Checking for periodic GC.
        [24.104s][info ][gc          ] GC(22) Pause Young (Concurrent Start) (G1 Periodic Collection) 1M->1M(32M) 0.778ms

    Разобрались? Я — нет. В JEP есть и подробный сурдоперевод каждой строчки лога, и как работает алгоритм, и всё остальное.


    "Ну и что, зачем я это узнал?" — спросите вы. Теперь у нас появились две дополнительные ручки: G1PeriodicGCInterval и G1PeriodicGCSystemLoadThreshold, которые можно крутить, когда станет плохо. Плохо ведь точно когда-нибудь станет, это Java, детка!



    Итоги


    В результате у нас на руках крепкий релиз — не революция, но эволюция, сфокусированная на улучшении перформанса. Ровно половина улучшений касаются производительности: три JEP-а про GC и один про CDS, которые обещают включиться сами собой, стоит только обновиться до JDK 12. Кроме того, мы получили одну языковую фичу (switch expressions), два новых инструмента для разработчиков JDK (Constants API и тесты на JMH), и теперь сообщество может лучше сфокусироваться над одним-единственным 64-битным портом на ARM.


    В общем, переходите на JDK 12 сейчас, и да пребудет с вами Сила. Она вам понадобится.


    Минутка рекламы. Совсем скоро, 5-6 апреля, пройдёт конференция JPoint, на которой соберётся огромное количество людей, знающих толк в JDK и всевозможных новых фичах. Например, точно будет Саймон Риттер из Азула с докладом «JDK 12: Pitfalls for the unwary». Самое правильное место, чтобы обсудить свежий релиз! Подробней о JPoint можно узнать на официальном сайте.
    JUG.ru Group
    831,00
    Конференции для программистов и сочувствующих. 18+
    Поделиться публикацией

    Похожие публикации

    Комментарии 69

      +2
      Shenandoah GC, кстати, нет в Oracle билдах (в т.ч. тех, что на jdk.java.net/12) — bugs.openjdk.java.net/browse/JDK-8215030
        0
        Проблема в том, что кто что там строит из OpenJDK — дело конкретных вендоров. Вот и начинается, «есть в OpenJDK (в исходниках проекта), но нету в OpenJDK (… сборках от Оракла)». Пусть это останется на их совести.
          0
          А так вообще можно делать? Просто одно дело, когда добавляют новые фичи, но совсем другое — когда отрубают имеющиеся.
            +1
            Ага, но откуда и чью сборку брать порекомендуйте тогда.
        +2
        Жалко, что Switch Expressions пока в превью. Выглядит интересно.
        • НЛО прилетело и опубликовало эту надпись здесь
          –3
          Очень вероятно, что «слизали» с Котлиновского when. Синтаксис и способ использования как-то подозрительно совпадают.
            +3
            Подобные операторы есть чуть ли не в каждом втором современном языке. А аналогичный case оператор появился в стандарте sql вроде в 92 году (если не в 86ом).
          0
          Большое спасибо за статью и обзор фич!
            +1
            «автомагически» — хорошее новое слово
              0

              Всё новое — хорошо забытое старое :) Очень рекомендую прочитать Jargon File, который составлял ещё старичок Эрик Рэймонд — это что-то вроде "википедии" тех лет. Содержание — по ссылке. Очень много остроумных слов.

              +1
              Oracle решили не поставлять Sheandoah ни с какой из своих релизных сборок — ни с той, что на jdk.java.net, ни с той, которая на oracle.com.

              Почему?
                +4
                Чтобы Shenandoah не конкурировал с их собственным сборщиком мусора (ZGC).
                  +1
                  Т.е. Shenandoah в официальном билде OpenJDK (официальный — на сайте самого OpenJDK) вообще не будет? Или только пока он экспериментальный?

                  В любом случае, какой-то бред, что официальный билд не содержит фичу, официально выпущенную в экосистему.
                    0
                    Что такое «официальный билд OpenJDK»? «Сайт самого OpenJDK» — это оракловская сборка. Нужно взять неоракловскую и всё. Сейчас пройдёт несколько дней и подтянутся все остальные основные производители сборок.
                      +2
                      Казалось бы, если у оракла есть своя коммерческая сборка, то сборка с сайта, на котором ведется основная разработка, хостятся сорсы и прочее — должна быть со всеми фичами, включенными в официальный релиз и присутствующими в сорсах. И не должна требовать подождать 2 недели на выпуск AdoptOpenJDK, как было у них в прошлый раз.
                  0
                  Ну, официальная причина другая.
                    0

                    Это что же, очередной "фатальный недостаток", получается?

                0
                Не совсем понял про switch. В примере Virgin Java Switch пропишет dayNum = 6 при понедельнике, пятнице и субботе, пример с новым выражением будет только 0/1. Как сделать такую же функциональность чтоб с малым числом букв осталось?

                int dayNum = switch (day) {
                    case MONDAY, FRIDAY, SUNDAY  -> 6;
                    case TUESDAY -> 1;

                или
                int dayNum = switch (day) {
                    case MONDAY -> 6
                    case FRIDAY -> 6;
                   ....
                

                ?
                  0
                  Если проводить аналогию с оператором when из Kotlin (который, вероятно, являлся прообразом для нового switch), то первый вариант (только в Java заставят case каждый раз писать, хе-хе). Иначе смысла особого нет.
                  +4
                  Почему 12? о_О
                  Я только на прошлой неделе начал книгу и в интернатах читать и везде 8-ая.
                  Все пропало? Надо искать что-то свежее?
                    +2
                    Везде 8-ая потому что после восьмой началась какая-то фигня, треш, угар и содомия, теперь новые джавы клепают по несколько в год, перед каждым релизом баги и инциденты сыпятся пачками, но почему-то тех, кто делает язык, это вполне устраивает. Лично я до сих пор ещё не увидел ни одну компанию которая требовала бы знания джавы выше восьмой.
                      0
                      Т.е. можно пока не кипешить и спокойно учить то, что есть. Это хорошо, спасибо.
                      А почему на сайте оракла jdk 8-ой? Они сами не верят в то, что релизят?
                        +1
                        Ну вообще-то на сайте оракла большая кнопка с 12 джавой, чуть более маленькая с 11 и 8, и упоминания о 6 и 7. Просто 9 и 11 джавы вышли не так уж и давно, чтобы все мигрировали с 8 (и более старых версий) на них.

                        Учить можно то, что есть, изменения в джаве не слишком радикальные, и основы, которые требуется учить, они, как правило, не затрагивают. Но быть в теме изменений новых версий стоит — когда-нибудь Java 8 станет тем, чем сейчас является Java 5.
                          0
                          Действительно. Сейчас зашел на сайт oracle — 12ая. 8-ка ещё и не обновляется больше.

                          Я вот сюда пападал из поиска — www.java.com/ru/download/win10.jsp
                          0

                          Чего "учить"-то тут все собрались? Ну вот знаете вы теперь про Constants API, что дальше делать с этим знанием кроме кругозора? Если вы будете работать над задачей, которая требует Constants API, точно разберетесь с этим за считаные часы.

                          0
                          Да и релиз JRE другой, кроме 8, и не встречается. Хотя на просторах интурнету встречал и 9, и 11. Теперь 12
                            0

                            Начиная с 9 jre более не посталяется, предлагается собирать по нужде с помощью jlink

                              0
                              Это как понимать, JRE новые есть или их нет? Или есть, но для гиков желающих заморачиваться собирать-разбирать?
                              Для обычных домохозяек, желающих запустить модерновое Java 12 приложение на своем ПК, Java где теперь находится?
                                0

                                для домохозяек JRE теперь поставляется вместе с используемой прогой

                                  0

                                  В докерном имаже вместе с приложеньем, например

                                  0
                                  Начиная с 9 jre более не посталяется

                                  В Java 9 и 10 JRE всё ещё есть: www.oracle.com/technetwork/java/javase/downloads/java-archive-javase9-3934878.html
                                  А вот с 11 её действительно нету.
                                0
                                Так хоть какое-то развитие.
                                  0

                                  Если не предпринимать радикальных изменений — будут стонать, что "Java не развивается, ява устарела". Если предпринимать — "ой вы нам всё поломали". Знаем, проходили уже

                                  0
                                  что такое «требовали знания джавы выше восьмой» и кому это вообще может быть нужно, даже если бы «джава выше восьмой» использовалась повсеместно?
                                    0
                                    Ну как, не знаешь, что такое exports, requires, uses, provides — не прошёл собес :)
                                    0

                                    Очень зря, на самом деле. Производительность сильно улучшается от релиза к релизу. Я тестировал свое поделие на 11-й и получил прирост около 40% по сравнению с 8-й. В 12-й есть еще пара улучшательств.

                                    0

                                    И это действительно большая проблема.
                                    Мы сидим на 8, и слезть не получается — вообще не понятно, где брать эти openjdk и кто будет делать security patches.
                                    Кровавому ынтырпрайзу нужны LTS. Банки не будут обновлять джаву раз в 6 месяцев.

                                      +1
                                      вообще не понятно, где брать эти openjdk и кто будет делать security patches

                                      Проблемы никакой нет. Я бы сказал, сейчас даже стало ещё проще. Просто качаешь с adoptopenjdk.net
                                        0

                                        Качаешь что? .tar.gz? В 2019 году? :)


                                        Попробуйте установить jdk 11 на Ubuntu LTS из официальных репозиториев, например. Там все ещё 10 — которая уже полгода не поддерживается.

                                          0
                                          .tar.gz

                                          а что, в 2019 году уже другие архивы в моде? :)

                                            0
                                            Попробуйте установить jdk 11 на Ubuntu LTS из официальных репозиториев, например. Там все ещё 10 — которая уже полгода не поддерживается.


                                            Нужно просто правильно устанавливать:

                                            sudo add-apt-repository ppa:openjdk-r/ppa \
                                            && sudo apt-get update -q \
                                            && sudo apt install -y openjdk-11-jdk


                                            stackoverflow.com/questions/52504825/how-to-install-jdk-11-under-ubuntu
                                              0

                                              Кто вендор? Как скоро выходят патчи на уязвимости?

                                              0
                                              Только так и нужно джаву ставить. Никаких пакетов. Серьезно.
                                                +1
                                                Только так и нужно джаву ставить. Никаких пакетов. Серьезно.


                                                Ссылка точно так же уязвима как и пакеты, так что — нет.
                                                  0

                                                  Нет, так никогда нельзя ее ставить. Серьезно. По той же причине, почему предпочитают RedHat, а не дистро от энтузиастов.


                                                  Бизнес будет сидеть на 8, пока не будет внятного вендора с LTS и патчами.

                                                    +1
                                                    Бизнес, у которого нет скилованных инженеров — да. Какой-нибудь ларёк по продаже сосисок, у которых среди двух тысяч сотруников только один джава-программист, по совместительству — заклинатель духов предков и админ прода. И поэтому им приходится вместо своего скилла и понимания перекладывать ответственность на всякие редхаты и заниматься карго-культом.

                                                    С другой стороны, я сам очень давно пользовался Дебианом, и практически каждая ошибка развертывания Java-платформы была связана с пакетами Дебиана и его мантейнерами. И точно так же как в техподдержке интернета давным-давно придумали универсальное правило для починки проблем домохозяек «выключите и включите», у меня теперь есть универсальное правило для любого Java софта на платформе Debian/Ubuntu: выключите (в смысле — удалите все пакеты всего джава-софта) и включите (вручную раскатайте zip-файлы, пропишите все нужные переменные и конфиги). Обычно это работает :-)

                                                    Частично это работает ещё и потому, что людям в таком режиме приходится вручную написать все конфиги и переменные в них, прогуглить их и понять, а не просто надеяться, что их правильно указал создатель дистрибутива. Доходит до смешного, что некоторые линукс-админы не знают, что такое PATH и где он устанавливается, и сама сакральная процедура раскатывания зипника JDK, прописывания JAVA_HOME и JAVA_HOME/bin в PATH нехило так расширяет их понимание платформы и класса проблем вроде «я установил пакет Java 11, а java -version показывает 8, спасите-помогите, ДЖАВА СЛОМАЛАСЬ».

                                                    В джава-мире процветает какой-то совершенно безумный карго-культ, согласно которому только Оракл может собирать «правильные» пакеты OpenJDK (на самом деле — кто угодно), или только пакетный менеджер может правильно их устанавливать (на самом деле — кто угодно, и может быть с помощью Ansible это делать ещё лучше), и так далее. Но к сожалению, сложилась критическая масса мракобесов, которые занимаются карго-культом и продолжают им заниматься вне зависимости от того, приводит это к каким-то осмысленным результатам или нет.

                                                    Я мог бы долго писать, но вот тут есть интервью, которое в точности описывает мою точку зрения на весь этот вопрос: habr.com/ru/company/jugru/blog/444652
                                                      0

                                                      Раньше я думал так же. Однако на работе, к сожалению, нужно работать, а не заниматься распаковкой архивов и настройкой PATH.
                                                      По той же причине я покупаю билеты на, скажем, jpoint — чтобы не тратить время на самостоятельное изучение, а послушать людей, которые этим занимаются побольше меня.


                                                      Архив, ну ок, могу, если нет другого выхода. Но все же не ясно, будут ли в open source важные патчи, или нужно покупать платную версию от оракла или другого вендора(какого?)?

                                                0

                                                Кто занимается эти сайтом? Как скоро выходят критические патчи?


                                                Что вообще люди используют в проде? Есть ли такие, что 11 используют? Интересен практический опыт. Используют ли, например, банки 11, или сидят на 8?

                                                  +2
                                                  Кто занимается эти сайтом?

                                                  Волонтёры. Но не кто попало, а высококвалифицированные люди. Например, лидер проекта Martijn Verburg является Java-чемпионом.

                                                  Как скоро выходят критические патчи?

                                                  Как обычно, примерно раз в три месяца. Как это всю жизнь делает Oracle.

                                                  Что вообще люди используют в проде?

                                                  Java 8 используется в 80% случаев. Java 11 пока слишком новая, поэтому серьёзные банки вряд ли на неё перешли.
                                                0
                                                >Кровавому ынтырпрайзу нужны LTS.
                                                Oracle же продаёт 11 LTS. Никаких проблем не вижу.
                                                  0

                                                  Вы в оракл работаете? Для вас проблем нет. Сколько там стоит джава за ядро теперь?

                                                    +2

                                                    Создаёте свой Docker-образ, в нём ваша программа на Java. Всё. Сам образ — это и версия релиза, и ваш артефакт для запуска.
                                                    В качестве поставщика Java (секция FROM в Docker-файле) используете, например, Zulu. Так вы и переходите на Java 11. При появлении патченных версий Java — подставляете свежий образ сборки в FROM.

                                                +1
                                                Ваш комментарий наполнен слухами и не даёт ответ. Уж лучше написали нормальное краткое объяснение, что версии Java ранее выпускались 1 раз в несколько лет, а после перешли на цикл выпуска 1 раз в полгода. Это понятнее чем ваше: "… началась какая-то фигня, треш, угар и содомия".
                                                Причина: желание поставлять новые готовые фичи тогда, когда они будут готовы, а не ждать «коллег» по году и более. Это отсылка к переносам модуляризации (Jigsaw).

                                                Или вы действительно не разбираетесь в вопросе и пишете комментарий?
                                              0
                                              А кто-нибудь может объяснить, почему GraalVM для тестов только с java 8 можно скачать? Почему нет версии с 9+
                                                0

                                                GraalVM вошёл в 9-ку и далее везде

                                                  0
                                                  Нет. В девятку вошёл только Graal Compiler. GraalVM как продукт — это вообще совершенно другая вещь по отношению к OpenJDK, он не может «войти» в OpenJDK.
                                                  0
                                                    0

                                                    Есть предположение (это не официальная позиция), что все клиенты, которые реально платят за GraalVM, сидят на 8, поэтому чинить косяки на 12 не имеет смысла. Оно собирается под свежие джавы (если собирать вручную), "но есть нюанс".


                                                    Если действительно интересна тема, можете зайти в чат @graalvm_ru в Телеграме и задать вопросы Олегу Шелаеву. Я давал ему инвайт на Хабр, но похоже, у него не так много времени, чтобы ещё и наш флуд тут непрерывно читать.

                                                      0
                                                      все клиенты, которые реально платят за GraalVM, сидят на 8, поэтому чинить косяки на 12 не имеет смысла

                                                      Тогда получается проблема стандартная, типоразмера "яйцо и курица": если не чинить косяки в новых версиях (хотя бы в 11, раз уж на то пошло, LTS всё-таки) — то все клиенты так и будут сидеть на 8, и никто их оттуда не сгонит. Не то чтоб это что-то плохое, но вроде в противодействие такому сидению Java и начала проводить такую агрессивную политику EOL в релизах — а значит какие-то причины были.

                                                        0

                                                        Возможно это плата за переход на релиз 1 раз в полгода? Переходы на новые версии отнимают слишком много времени от разработки и поддержки текущего проекта.

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое