После шести месяцев разработки компания Oracle выпустила (https://www.oracle.com/corporate/pressrelease/java-11-092518... платформу Java SE 11 (http://www.oracle.com/technetwork/java/javase/downloads/inde... (Java Platform, Standard Edition 11), в качестве эталонной реализации которой используется открытый проект OpenJDK. В Java SE 11 сохранена полная обратная совместимость с прошлыми выпусками платформы Java, все ранее написанные Java-проекты без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 11 (JDK, JRE и Server JRE) подготовлены (http://jdk.java.net/11) для Linux (x86_64), Solaris (SPARC), Windows и macOS. Разработанная в рамках проекта OpenJDK эталонная реализация Java 11 (http://openjdk.java.net/projects/jdk/11/) полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами.
Java SE 11 отнесён к категории выпусков с длительным сроком поддержки (LTS), обновления для которого будут выпускаться до 2026 года. Выпуск обновлений для прошлого промежуточного выпуска Java 10 прекращён. Прошлая LTS-ветка Java 8 будет поддерживаться до декабря 2020 года. Следующий LTS-релиз намечен на сентябрь 2021 года. Напомним, что начиная с прошло выпуска проект перешёл на новый процесс разработки, подразумевающий более короткий цикл формирования новых релизов. Новая функциональность теперь развивается в одной постоянно обновляемой master-ветке, в которую включаются уже готовые изменения и от которой раз в шесть месяцев ответвляются ветки для стабилизации новых выпусков.
Из новшеств (http://openjdk.java.net/projects/jdk/11/) Java 11 (https://blogs.oracle.com/java-platform-group/introducing-jav... можно отметить:
- Поддержка TLS 1.3 (https://www.opennet.me/opennews/art.shtml?num=49126) (RFC 8446 (https://tools.ietf.org/html/rfc8446)), который отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.), работает только в режиме forward secrecy (компрометации одного из долговременных ключей не позволяет расшифровать перехваченный сеанс), обеспечивает более высокую производительность, поддерживает режим 0-RTT (устраняет задержки при возобновлении ранее установленных HTTPS-соединений), поддерживает
потоковый шифр ChaCha20 (http://cr.yp.to/chacha.html), алгоритм аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), ключи аутентификации на основе цифровых подписей Ed25519, HKDF (https://en.wikipedia.org/wiki/HKDF) (HMAC-based Extract-and-Expand Key Derivation Function), ключи на основе алгоритмов x25519 (https://en.wikipedia.org/wiki/Curve25519) (RFC 7748 (https://tools.ietf.org/html/rfc7748)) и x448 (RFC 8031 (https://tools.ietf.org/html/rfc8031));
- Стабилизирован (http://openjdk.java.net/jeps/321) новый API для разработки HTTP-клиентов, поддерживающий HTTP/2.0 и websockets. Новый HTTP Client API пришёл на смену API HttpURLConnection.
- В состав включены инструментарии Java Mission Control (http://www.oracle.com/technetwork/java/javaseproducts/missio... (JMC) и Java Flight Recorder (https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-g... (JFR), который ранее поставлялся только для платных подписчиков. Инструментарий предоставляет средства для мониторинга, диагностики, профилирования и выявления утечек памяти. JFR позволяет получить доступ к детальной низкоуровневой информации о работе JVM и даёт возможность эффективно анализировать текущие данные и произошедшие события без негативного влияния на производительность.
- Поддержка (http://openjdk.java.net/jeps/329) потокового шифра ChaCha20 (http://cr.yp.to/chacha.html) и алгоритма аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), разработанных Дэниелом Бернштейном (Daniel J. Bernstein (http://cr.yp.to/djb.html)), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальных аппаратных ускорителей;
- Поддержка системы управления доступом Nestmate (Nest-based access controls (http://openjdk.java.net/jeps/181)), которая адаптирована для корректной обработки доступа с учётом вложенных типов. Nestmate обеспечивает возможность обращения к приватным частям внутри группы классов, логически относящимися к одному и тому же компоненту, но компилируемым в разные файлы с классами. Новый механизм управления доступом позволяет избавиться от необходимости подстановки компилятором специальных промежуточных методов обеспечения доступа;- Формат файлов с классами Java (.class) расширен (http://openjdk.java.net/jeps/309) поддержкой динамически создаваемых констант (пул CONSTANT_Dynamic). Загрузка CONSTANT_Dynamic приводит к делегированию создания констант в метод bootstrap, по аналогии с тем, как в метод bootstrap делегируются операции связывания при вызове invokedynamic;
- Предложен (http://openjdk.java.net/jeps/333) экспериментальный сборщик мусора ZGC (Z Garbage Collector), работающий в пассивном режиме и насколько это возможно минимизирующий задержки из-за сборки мусора. Время остановки при использовании ZGC не превышает 10 мс. При этом ZGC может работать как небольшими, так и с огромными кучами, размером от нескольких сотен мегабайт до многих терабайт;
- Обеспечена (http://openjdk.java.net/jeps/330) возможность запуска программ, поставляемых в форме одного файла с исходным кодом.
URL: https://www.oracle.com/corporate/pressrelease/java-11-092518...
Новость: https://www.opennet.me/opennews/art.shtml?num=49336
Блин, что мне теперь новое железо покупать?
А, не проще - не использовать Java!...P.S.
Интересно что, никто за сколько там десятилетий - не классифицирует Java&JS - как ОСь...
(пусть и паразитического или иначе сказать дочернего характера - поверх других ОСей).
Т.е.всякие [гугло] WebOS'и - обкакиваются за всё "хорошее": а, тут молчок......* WebOS'и - к которым можно включить уже давно и винды - привязанные DRM'ом и просто валидациями и несанкционированными вылазиньями в сеть (уже с времён w95, был даже текст на тему того что мол ныне Windows 95, на самом деле, клиент распределённой в мире ОС; правильней клиент трояна),
про никсы зависящие от драйверов и портов из сети - уже на этапе установки, т.е.даже просто от активности самой сети - тем более неговорю.
> Java&JSОдин мой друг путал Java и Javascript и теперь он в армии (с)
"В Java SE 11 сохранена полная обратная совместимость с прошлыми выпусками платформы Java" - наглая ложь.В интерфейс Collection добавлен toArray(IntFunction<T[]>) Default Method, перегружающий toArray(T[]). Это привело к несовместимости со старым кодом, в котором есть вызов toArray(null). Теперь такой вызов приводит к ошибке компиляции и должен быть изменён на аналогичный с кастингом null в требуемый тип.
> toArray(null)А зачем такое вообще писать-то?
Прямо практический кейс, всегда так делаем, ага...
Учитывая, что вызов toArray(null) в рантайме выбросит NPE, твой пример просто нереально полезен.
Зачем же этот пример указан в Release Notes?
нечего пользоваться хаками не будет проблем с совместимостью
Любая программа - хак.
И хак ЦПУ ;)
> привело к несовместимости со старым кодом, в котором есть вызов toArray(null).Ты делаешь Java больно!
Так он про то и пишет что, нехочет же - прийдётся отказаться от более новых версий Java ;)
И что теперь никогда не будет 32 разрядных версий? Даже в LTS. А что же делать с большим парком компов на большей половине которых стоит 32 разрядная Винда?
>> А что же делать с большим парком компов на большей половине которых стоит 32 разрядная Винда?Множество вариантов, среди которых:
- Переименовать "парк" в "свалку";
- Сидеть на старых релизах Java. На 8-й, например, а еще лучше на 7-й (чтобы еще и поддержку винХР гарантировать);
- да тысячи их, вариантов-то.
Кстати говоря, хоть JRE8 и не поддерживалась XP официально, но она работала.
Это ск.всего значит что она там не тестировалась, а работает - понятие растяжимое же...
Java 8 тоже LTS, будет поддерживаться до декабря 2020 года (Personal User End of Public Updates).
https://www.oracle.com/technetwork/java/javase/eol-135779.htmlА если нужны новые фишки языка то... может начать использовать kotlin? Тогда можно собирать хоть для java 1.6.
Похоже, теперь это глобальная тенденция... все, кому не лень (точнее все, кому лень) перестают поддерживать 32битные x86 системы. К этому нужно привыкать...
Процессоры Opteron выпущены в 2003-м году. За 15 лет оборудование можно было бы и обновить.
> Процессоры Opteron выпущены в 2003-м году. За 15 лет оборудование можно было бы и обновить.ia32 используют из-за меньших требований к объёму памяти, когда на том же объёме можно запустить больше процессов, обслужить больше одновременных соединений и т.д.
Причём тут процессоры? Сопроцессор выпустили ещё раньше, так давайте откажемся от целочисленной арифметики?
> ia32 используют из-за меньших требований к объёму памятиВроде логично, 32-х битные указатели и т.д. Но практика! Дистрибутив debian 9 с xfce что 64-х битный, что 32-х битный со старта занимает 280 мегабайт, никакой разницы, может конечно под виндой картина другая.
Это у Вас что-то с вашим дебианом...Как щас помню - CentOS 6 i386 жрёт примерно на 30% меньше рамы.
За точность цифр отвечать не берусь. Только помню, что на тощую VPS-ку (512 МБ рамы) поставил 64 битную CentOS - выжрало раму полностью. Снёс. Поставил 32 битную - осталось достаточное количество свободной рамы.
P.S. По сей день живёт CentOS 6 i386
> За точность цифр отвечать не берусь. Только помню, что на тощую VPS-ку
> (512 МБ рамы) поставил 64 битную CentOS - выжрало раму полностью.ядро съело 512 мег? ну просто сенсация! на всех vps-ах 64 бита и 7-й цент, всё пучком. ещё и жабка помещается...
250 MB CentOS 7что-то не так у вас
Требования к памяти ниже, ну так и скорость обработки ниже из-за половинного использования регистров процессора. Собственное, дальше вопрос про одновременные соединения. А будет ли их больше в 32-режиме? Слишком абстрактные размышления. Надо сравнивать на конкретном софте.> Причём тут процессоры?
А процессоры здесь при том, что раньше была аргументации в том, что оборудование не поддерживает 64-х битный режим. Но сейчас уже 15 лет прошло как серверы на AMD64 начали переводить.
> Сопроцессор выпустили ещё раньше, так давайте откажемся от целочисленной арифметики?
При чём здесь сопроцессоры - я не понял.
> Требования к памяти ниже, ну так и скорость обработки ниже из-за половинного использования регистров процессора.https://en.wikipedia.org/wiki/X32_ABI
К сожалению, практически не встречается... :-(
> ...15 лет прошло как серверы на AMD64 начали переводитьДело в том, что кроме bare-metal есть ещё огромное количество виртуалок. Причем, я уверен, большая часть этих виртуалок имеет меньше 4 гиг рамы - зачем там 64 бита?
> меньше 4 гиг рамы - зачем там 64 бита?Например, улучшенная безопасность, так как для ASLR используется не 12 битов (а на Windows так вообще 8), а 28 (на Windows 8-19).
64-битный код может использовать больше регистров, что позволяет реже лазить в основную память, а значит ускоряет выполнение программ, особенно PIC-код, ибо при его выполнении один регистр всё время занят под base offset, и для 32-bit x86, где регистров мало, нехватка этого регистра просаживает производительность. Да и сами регистры на 64-битных процессорах в 2 раза больше, значит можно за меньшее количество действий обработать такой же объём данных.
Тут опять стоит вспомнить (метрворожденный) X32 ABI
> Тут опять стоит вспомнить (метрворожденный) X32 ABIа почему вы называете его мертворождённым?
> 64-битный код может использовать больше регистров, что позволяет реже лазить в основную память, а значит ускоряет выполнение программ- Ага, кэши прям отменили значит...
А, то что доп.регистры тоже надо пересохранять при интенсивных операциях - т.к.их всёравно нехватает ничего?...
Но, прикол в том что и x86 хватает - в Intel не идиоты сидят когда его делали.
А, то что расширенные регистры требуют увеличить размер команд, да и прочие команды - тоже, особенно при dword в памяти или из-за qword в адресации - хана L1code кэшу! Да и L2 с L3 - не резиновые. Ускорение x86-64 может быть только в приложениях ленящихся сделать кэш чтобы влазить в 2-3GB адресного пространства в x86, всё остальное маркетинг (хоть конечно результаты хоть любых тестов можно подтасовать - маркетингово чуть замедляя режим x86 относительно x86-64 - тем более что, так уже делали: 16 битный vs 32)
* "Но, прикол в том что и x86 хватает - в Intel не идиоты сидят когда его делали" - речь про то что обращение к типично-локально перемнной, т.е.в стэке в L1, вместо регистра - всего несколько тактов, а то и один - в зависимости от расположения команд, в то время как любое прочее обращение вне L1/2/3 к RAM - сотни тактов(которые убивают вообще любую оптимизацию, а так сделанно - маркетинго для отделения серверного сегмента рынка, где всё типа чуть быстрей, а реально - тут исскуственно тормозней), так же как и ошибочные предсказания которых тоже обычно немало (официально писалось где то - ~60%, т.е.всего +5% эффективность относительно 50:50, т.е.эффективность меньше погрешности любых benchmark'ов..., так что эта оптимизация в ЦПУ у Intel 20 лет назад - была тоже: чисто маркетинговая).
Пожалуйста, хватит использовать слово "ибо". Оно считалось устаревшим еще в 1930-х.
> Требования к памяти ниже, ну так и скорость обработки ниже из-за половинного использования регистров процессора.Вроде можно использовать 32-битную модель памяти и 64-битные регистры. На генту, конечно же. И ядро собирать ручками.
> А что же делать с большим парком компов на большей половине которых стоит 32 разрядная Винда?Повторять мантру "Write once, run everywhere".
+1К слову, начатую ещё Б.Гейтсом...
https://gist.github.com/KOLANICH/0c70b53751d60f663871e362180...
даешь новую версию каждый месяц !
В Google Java
Все аноны уже давно перешли на .net core , запускается как на линуксе, так и на виндовс ХР. Уже 20й проект по счету делаю. Наконец могу сказать, это именно та технология которая мне нравится, и которая впереди всех остальных.
Я наоборот несколько лет назад перешел с .NET на Java, обратно не хочу.
Интересно. Можешь плз написать почему на пару предложений?
В то время из-за кроссплатформенности. Я тогда сидел на винде и впервые попробовал Linux. Мне понравилось и у меня встал вопрос, как запустить мое десктоп-приложение на WPF в Linux. Оказалось что никак, пришлось переходить на JavaFX (оно тогда еще в beta версии было). Библиотек для Java гораздо больше, да и сама платформа популярнее. Также не нравилось что в дотнете все прибито гвоздями к Microsoft - одна ОС, одна IDE. А с Web приложениями тем-более. Писать под виндой чтобы запускать на вин-сервере - ужас, потому-что в качестве серверной ОС, Linux уже тогда был лидером этого рынка.
А по производительности как?
А по использованию CPU,RAM?
Какая разница какая производительность, если нет большей части функционала?
Пол JEE своими руками? ;)
Ну вот, к примеру, в роли бэкенда оно неюзабельно от слова совсем, в тестах зафейлило 15% реквестов. Оно ещё и работает медленнее явы (см. Table III, Test Network Time, By Test Type), но кого это уже интересует?
https://www.researchgate.net/publication/325534947_Performan...
> А по производительности как?По производительности раньше было хуже, сейчас гораздо лучше стало
> А по использованию CPU,RAM?
Еще жесткий диск нужен, ну и монитор там, и тому подобное
Наделла, залогинься.
Юзаю Mono, собрал свой билд, заюзал частично код с .Net Core.
Полет отличный )) В общем надо уметь готовить.
А C# - суперская поварёшка.
Каким образом у Вас .NET Core запускается на Windows XP? SDK устанавливается, но "dotnet не является приложением win32", а рантайм не устанавливается с ошибкой "0x80070001 - неверная функция".
Про добавление var'a все забыли?
Уже было в JDK 10.
https://www.opennet.me/opennews/art.shtml?num=48300
он про var'ы для лямбд:Local-Variable Syntax for Lambda Parameters
http://openjdk.java.net/jeps/323это появилось только в 11
Известно ли, 11-я жабка попадёт в CENTOS 8?
И когда оно вообще будет?
Всем добрый день!!!! Данный выпуск Java SE 11 вышел практически в срок, как и говорилось тогда, - на середину 20-х чисел сентября ИМЕННО этого года!!!!Что касаемо отсутствия поддержки x86 (32-х разрядная), можно сказать следующее:
Да, это плоховато. Но не смертельно. Сейчас, если кто не в курсах, немалая часть программ на Java, как в виде консольной версии, так и GUI (графический интерфейс на AWT/Swing, SWT/JFace) нормально работают при Java SE 8 (длительно поддерживаемая), при Java SE 9 выдавало, что не удается обнаружить JRE, даже почему-то x64 версия не порадовала. Даже LibreOffice "распознавал" только JRE 8 (из личных наблюдений). Хотя кстати, в LibreOffice, вообще исходя из последней информации нацелены на отказ от Java в ближайшей перспективе. Некоторые модули "перебазировываются" на Python. Что касается Java и её JRE и JDK, - применяется ветка Java 8. Сейчас я бы не советовал торопиться с переходом на Java SE 11, но для возможности убедиться в работоспособности Java SE 11, не грех её попробовать. НО... Для тех, у кого немало Java программ работает на x86 Java SE 8, категорически не советую её деинсталлировать, потому как исключительно при наличии только JRE 9/10/11 исключительно в x64, программы могут не запуститься. LibreOffice в том числе тоже, - не только из-за того, что зачастую предлагается x86 редакция этого офисного пакета, а дело из-за того, что есть функционал, для которого требуется наличие совместимой версии. Почему я приобщился к Java несколько лет назад, - меня порадовало, что Java, в отличие от C/C++ имела свои встроенные средства с графикой, работа с сетью, особенно у меня экстаз и балдёж от того, как легко и интересно иметь дело с парсингом XML средствами Java, сильно много усилий и времени не потребовалось, чтобы понять из исходных текстов, как работает парсинг. Зачем далеко ходить, если есть JDOM, SAX, StAX (потоковый XML, проще говоря). Java оказалась одной из немногих, освоить которую значительно легче. Не спорю, что было бы не лишним испробовать возможности "крипто цеха", в лице поддержки ChaCha20 и Poly1305. По поводу сказанного qrKot'ом здесь по комментариям, касаемо применения предыдущих веток, вплоть даже до Java 7, - нууу, это как экстренный вариант в целях сохранения работоспособной версии Java, а уж тем более учитывая, что частному владельцу ПК, имеющему один-два ПК (не важно ноутбук или стационарный ПК) ещё более-менее под силу перевести на актуальную ОС свои компьютеры, тогда как, уважаемые, не забывайте, что есть фирмы, а то и госконторы, сотрудники которых просто так не могут позволить перевести компьютеры "по последнему слову прогресса", сложнее всего обстоят дела у тех, у которых в штате до 20 ПК, немалая часть из которых - Windows XP/7 в x86, ладно бы еще x64, но не всё так просто как казалось бы. А в заключении этого комментария могу отметить, что Java всё-таки не стоит на месте. Всем мира и удачи!!!
> Сейчас я бы не советовал торопиться с переходом на Java SE 11Не всегда есть выбор. Вот например сейчас в Debian Unstable (а значит и в Testing) начали собирать пакеты с помощью Java 10, при чём в формат байт-кода Java 10. Соответственно, Java 8 этот байт-код выполнять отказывается. И как на Java 8 остаться? Походу никак. А потом и на Java 11 так же перейти придётся.
>начали собирать пакеты с помощью Java 10, при чём в формат байт-кода Java 10Ну что сказать про мантейнеров Debian Unstable? А может и не надо ничего говорить.
Да ладно, так и скажите что они очередную порцию взятки-доната от Oracle получили.
Всё же тут очевидно и однозначно, только так в этом мире популяризуются [говно]продукция.P.S.
А, на вопрос выше что делать - никогда не использоввать чужое.
Иначе - неудивляться что вас поимели.
> сохранена обратная совместимость с прошлыми выпусками платформы Java, все
> ранее написанные Java-проекты без изменений будут работоспособны при запуске > под управлением новой версии.Это ложь. Еще кто-то на этот булшит ведеться?
по сравнению с питоном, например, они эталон стабильности
Угу, с нынешними браузерами на iLO 2 попробуйте зайти и открыть консоль
>с нынешними браузерами на iLO 2 попробуйте зайти и открыть консольБум.
ERR_SSL_BAD_RECORD_MAC_ALERTИ причём здесь java?
applet-ы её выпилили тоже клепатели браузеров, а не Оракле.
> ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMACЕсть ощущение, что мы имеем дело с очередным внедрением бэкдора от АНБ. Протокол https создает защищенный канал связи между компьютерами в сети, сохраняя анонимность клиента. Это кроме всего прочего позоляет запутывать трафик, используя луковичную маршрутизацию. У АНБ стоит задача собрать досье на каждого человека, для чего нужно контролировать весь трафик в сети. На 2013 год они уже читали трафик, проходящий через серверы в своей юрисдикции, вымогали закрытые ключи, взламывали устаревшие версии TLS.
Если у АНБ есть возможность вскрывать ChaCha20, и он станет применяться повсеместно, то проблемы https для них больше не будет (а из интернета уйдут остатки приватности).
Несколько лет назад АНБ представило на стандартизацию свой блочный шифр Speck конструкции Add-Rotate-Xor. Известных атак на полнораундовую версию не существует. Однако можно предположить, что они есть у АНБ и возможно требуют специализированных суперкомпьютеров, а может и нет.
ChaCha20 это так же Add-Rotate-Xor.Что, кроме разработки шифра Speck такой же конструкции, намекает на вмешательство АНБ? Попробую коротко объяснить разницу между AES и ChaCha20.
Раундовая функция AES (Substitution-Permutation-Network):
1. Substitution
Побайтовая подстановка через S-Box конструкции Ниберг, состоящий из нелинейной части (возведение байта в степень 11111110 в поле Галуа GF(2^8), что эквивалентно взятию обратного элемента поля) и линейной (XOR каждого бита с 4 битами справа от себя).
2. Permutation
Блок представляется как матрица 4x4 байта, строки циклически сдвигаются на номер строки влево.
Блок представляется как набор 32-битных чисел. Каждое число умножается на определенную MDS матрицу в поле Галуа.Раундовая функция ChaCha20 (Add-Rotate-Xor):
1. Add сложение 32-битных чисел.
2. Rotate сдвиги битов.
3. Xor побитовое сложение по модулю 2.Допустим, у атакующего есть какое-то количество пар открытый текст - шифртекст. Что отделяет его от раскрытия вашего ключа? Нелинейность (при условии, что остальные элементы шифра подобраны правильно).
Нелинейное преобразование AES хорошо изучено в теории, менять его имеет смысл только при увеличении размерности (2 байта вместо одного), оно оптимально.
Нелинейное преобразование ChaCha20 это обычное сложение двух 32-битных чисел.
И то, и другое - security through obscurity. Никто (?) не умеет взламывать симметричные шифры потому, что у всех (?) нет для этого и интеллекта, и необходимой математической подготовки, и мотивации одновременно.
SHA тоже было сделано NSA. И что?
Ну запретити ChaCha20 в браузере, останется AES (тем более хардварно кирпичами поддерживается).
Да, аналогично думаю:> "Протокол https создает защищенный канал связи между компьютерами в сети, сохраняя анонимность клиента"
Чего чего...
В общем - гониво или сознательная деза...
> В общем - гониво или сознательная деза...Пару кг лапши на уши юзеров. Все как обычно.
Это уже вопрос к Eclipse...
Java 11 Trap (по поводу коммерческой использования именно этой сборки):
https://blog.joda.org/2018/09/do-not-fall-into-oracles-java-...
С Майнкрафтом совместима?
Нет, не совсем; ждём, пока cpw обновит (хотя бы) Forge для работы на этой LTS.
java beans as part of jEE?
Как же терь в майнкрафт играть ? Лаунчер под джаву новую годами пилят
Makagiga разработчик еще под старую версию не допилил - уже две ветки сделал чтоб как-то успевать, а тут еще задачка.
выкинули javafx. А говорят что обратную совместимость сохраняют. Даже уже собранные программы с javafx не запустятся.
JavaFX выкинули из стандартной поставки, он вынесен в отдельный модуль, ты так же можешь добавить его в проект и использовать.