Взагалі незгодній із тим, щоб дивитися на Netty — це вже на стільки минуле сторіччя, що воно нікому для нових проектів не потрібно. Якщо справа саму у мережевому програмуванні, то я ДУЖЕ рекомендую дивитися на:
1. Helidon.
2. Quarkus
3. Spring Boot.

Взагалі, жодна книжка вам не допоможе так якісно як книжки по підготовці до сертифікації Java 17 (можна почати звідси www.google.pl/...​tilmEAAAQBAJ?hl=en&gbpv=0).
Далі треба розуміти що саме вам цікаво, якщо Spring — то шукати матеріали по Spring 6.
Щодо Java core — то можна просто подивитися перелік JEP-ів які були впроваджені, або пошукати матеріали по проектах OpenJDK типу Project Amber, Project Loom, Project Panama, Project Valhalla.
Як классика жанру, то можна почитати ось це www.manning.com/...​oks/modern-java-in-action.
Далі цікавою книжкою буде ось ця книжка мого колеги www.amazon.com/...​lai Parlog&s=books&sr=1-1

Ну і для фіналу — https://dev.java/, це наш комьюініті портал для вивчення Java, ми його дуже якісно ведемо і там є що почитати і чому повчитися.

Беру свої слова назад. Так, дійсно, 7.6 від 24 лютого підтримує JDK 19. Мене більш турбує сама затримка у підтримці, наразі це 5+ місяців. Із мавеном ситуація зовсім інша.

Valhalla рухається вперед, скажу відверто. Але спочатку будуть зміни які не будуть помітні ззовні, лише зміни в JDK/JVM.

Gradle взагалі якась пічаль, він досі не підтримує JDK 19, тобто, вже рік як нічого не робиться там. Тому очевидний вибір — mvn.

Чекати — вже не найефективніша стратегія. Треба брати приклад із великих екосистем типу Spring. Команда там вже працює над адаптацією нового функціоналу. Теж саме стосується стеку DataStax, там вже перевели Cassandra 4.x.x на JDK 19+. Тобто, чекати ще одного LTS не вигідно, краще і дешевше буде мати готову кодову базу під новий функціонал, а не наздоганяти потяг, що несеться у світле майбутнє Java. Якщо цікаво, то можемо поспілкуватися на цю тему.

Великими релізами вважаються ті, що мають довгострокову підтримку. Наступний такий реліз — Java 21 (до цього була Java 17), тобто, за 6 місяців.

Чи планується стандартний біндинг до Vulkan API ?

Наразі ведеться робота над проектом Lanai, який буде мати підтримку і Vulkan, i Metal. Але давати якісь прогнози відносно того коли саме буде реалізовано та релізнуто — важно сказати. Персонально, із того що я бачу, можу сказати, що навіть зараз можна реалізувати Vulkan API на Java використовуючи Project Panama API, для початку цього буде достатньо. Якщо цікаво, то можемо окрепо поспілкуватися на цю тему.

З точки зору розвитку Java автор вказав настільки мало, що аж трохи незручно.

Ось на що треба було звернути увагу.
1. Перехід на JDK 9 та Project Jigsaw. JDK стає модульною і завдяки цьому модулі можуть розвиватися самостійно і зі своєю швидкістю.
2. Перехід на JDK 11 та jlink. Відмова від JRE стає логічним розвитком платформи, бо вже нема сенсу тримати загальні рантайми для всіх, бо можна зібрати власний за 1 команду із відповідною кількість модулів JDK.
3. Project Amber. Java records, patter matching for switch, for records, switch expressions, switch statements, text blocks, string templates, sealed classes — мені продовжувати? Сергій, нажаль, майже нічого про це не написав.
4. Project Panama. Титанічний зсув відносно існуючого JNI, імплементація C ABI на рівні рантайму. Векторна алгебра чого лише варта. Сергій про це нічого не написав...
5. Project Loom. Тут вкрай багато змін: віртуальні потоки, переробка усіх блокуючих методів на неблокуючі (в залежності від типу потоку); структурний паралелізм замість асинхронного програмування; extent locals замість thread locals, контінуації.
6. Дуже багато нових інструментів JDK типу jlink, jdeps, jextract та jpackage (для створення пакетів типу deb/rpm).
7. Стосовно JDBC я можу сказати наступне. По-перше завжди іде зв’язка із пулом з’єднань, ці пули або мають свій ExecutorService, або можуть працювати із наданим ззовні (hikaricp), або працювати в наслідувати батьківський поток. Так от, нема сенсу якось переробляти JDBC, бо із віртуальними потоками виклики більше не є блокуючими, тощо.
8. Трохи утілітарності: jshell (та jshell-скрипти), jwebserver — така собі альтернатива пайтоновському simple http.
9. GraalVM згадується, але без контексту Project Leyden.
10. А ні слова про вбудований моніторинг, але ж вже впроваджений JDK Flight Recorder, який дає змогу відслідковувати статус застосунку і JVM у реальному часі за допомогою JDK Mission Control.
11. Java Management Service не згадується, на превеликий жаль.
13. У контексті ZGC не згадується що в цього GC найкоротші паузи (<10мс) і нема різниці на скільки велика купа у додатку. Ба більше того, не згадується generational ZGC, де паузи <1ms.
14. Стосовно Project Valhalla. Value types потрібні не лише для того, щоб мати компактніше відображення на пам’яті, а й реалізувати підтримку тих типів даних яких нема наразі, наприклад long long.
15. Хоч про цикл релізів вказаний вірно, але не вказано те, що були впроваджені різні рівні включень нового функціоналу: incubated, integrated, preview, standard. Від першої стадії до останньої можуть пройти роки, наприклад, Loom так існує з 2018-го. Далі треба зазначити, що окрім 2-х релізів на рік існують і LTS релізи, які випускаються один раз на 2 роки і що Oracle офіційно й безкоштовно підтримує новий LTS перший рік для всіх.

Якщо я щось ще пригадаю, то допишу у коментарях нижче.

Якщо міські ради визнають ваш бізнес як критичний, то лише двум, а так трьом.

Так, авжеж. Вже ж десь в інтерв’ю було сказано, що вся історія із єВідрядження була тимчасова до впровадження правил бронювань. Але ситуація така, що навіть маючи бронь виїхати з країни не можна, бо Постанова № 57 Кабміну таке не передбачає.

Ба більше того, ось кабмін викотив правила, а про процедуру вони забули?

Ну в мої власні очікування такі, що лише ТОП-3 компаній зможуть щось там «нарєшать» із державою, а всі інші — ні, бо не дотягують по критеріях. Тому робимо висновки, що для держави ІТ не є, а ні пріорітетною, а ні стратегічною галуззю.

У Львові важко знайти новобудову із газом. Там всі на електриці, тому якщо нема світла, то краще мати походний примус та запас балонів. Те ж саме стосується води та опалення.

Це і зветься 99% від ринку ІТ-компаній, ті хто підпадає під виставлені критерії це ТОП-3 аутсорсерів, усе що нижче 4-Ї сходинки — їх не рахують, ось так і діє ІТ асоціація, на блага найбільших за рахунок найменших.

Фактично, це означає, що маленькі компанії з оборотом менше 8М евро за квартал просто опиняться за бортом або як зараз модно казати «десь під Бахмутом».

Критерії «критичних галузей» не враховує 99% ІТ-ринку. То й ця новина жодним чином не має відношення ІТ, бо майже ніде нема офіціних працівників, лише ФОПи. А бронювати ФОПів по закону не можна.

Тому сидимо й «обтікаєм».

прос С# я взагалі мовчу, бо ця мова специфічна і хоч входить в ТОПи, але не є вибором № 1, 2, 3, 4 і навіть 5 для будь яких розробок
це дуже сміливе твердження :)

це не мої слова, це фактична статистика від чотирьох різних джерел.

Boost є набором бібліотек для C++, він не міг мати фічі, яких не було в C++
Просто темплати у C++ — це така собі мова у мові, тому накрутити там можна було ого-го, але все тільки у межах синтаксису і семантики самого C++

С++ в вакуумі не існує, С++ без буста — не є досить розповсюдженим рішенням, бо всі хто писав на С++ знає, що Boost і є C++ та його стандартна бібліотека: кращій інтерфейс роботи із потоками, L7-програмування (beast) та низькорівневе мережеве програмування, коллекції, і так далі.

Дуже рекомендую, бо впровадження такого нового функціоналу має вплив на усю JDK. Скажу так, що мені власно не вистачило сил передивитися чейндж-реквест для virtual threads в 11 тисяч файлів, але мав змогу протестувати код і можу сказати, що нововведення — радикальні з точки зору фунціональності, але майже зовсім непомітні з точки зору програмування.

і тому Scala — одна з найменш популярніших мов програмування за останні роки, вона не потрапляє в ТОПи зовсім, прос С# я взагалі мовчу, бо ця мова специфічна і хоч входить в ТОПи, але не є вибором № 1, 2, 3, 4 і навіть 5 для будь яких розробок.

А багато з них навіть були у c#

Так можна сказати про довільну мову програмування, наприкла, C++ Boost мав фічі яких не було в C++. С має все чого не має Python і так далі.

Я скажу вам так, можна говорити, що певні фічі Java зʼявилися досить «піздно» відносно інших мов, але швидкість адаптації нового функціоналу у додатках стала на стілки повільною і млявою, що хоч релізь усі нови проекти в OpenJDK зараз, все одно їх адаптують за десятеліття післе релізу (про це й ця стаття, все застаріле й даб Боже JDK 8, а не 6).

Авжеж, авжеж, чому не на 20 років одразу?

Подивіться на інші мови програмування, наприклад Python, ця технлогія майже така ж за віком як і Java, але чомусь досі не вирішені ключові проблеми мови типу 1 потоку, неоптимізованного компілятора. Подивіться на C та С++ — ці мови все ще складні та важкі для опосередкованого девелопера, rust — не робить життя краще. Єдиним щось новим став Golang, але ця мова вкаладає більше проблем у розробці та підтримці, а ніж його бонуси. Про JS я взагалі мовчу, бо поки я пишу цей текст народився і помер новий фремворк та зʼявилася нова альтернатива до TypeScript...

А політика платної JDK взагалі призвела мало не до року різних корпоративних зборів організованих різного роду технічними директорами, щодо подальших комерційних перспектив платформи як такої.

Де це ви таке прочитали?! JDK безкоштовна за обома ліцензіями типу NFTC та GPLv2+CP.

Судова тяганина с Google підірвала комерційний інтерес у багатьох замовників.

Тут коментувати важко, Google знали що робили і робили це із повним усвідомленням наслідків.

А замість Java розробники усе частіше обирають Kotlin.

Це взагалі не так, все більше людей чи перейшли, чи планують переходити від Kotlin на Java згідно останнім опитуванням розробників. Наразі нема сенсу взагалі дивитися на kotlin, якщо ви не пишете під Android. Та й то, багато хто пише на Flutter і їм норм, бо кросс-платформа.

Java — норм мова, норм середовище, можна писати досить багато всього. Не вистачає тільки корутин, але їх можна зловити в котліні.

дивіться на Virtual Threads починаючі із JDK 19. Ось тут я детально описав dou.ua/forums/topic/38676

Не згодний, а ні трохи. Із появою підтримки C ABI через Foreign Function & Memory API (OpenJDK Project Panama) відкрився новий цілий ринок технологій яких не існувало написаних на нативній Java (без С/C++).

До того ж, відбуваются революційні зміни у самій Java, чого вартують віртуальні потоки, value-types, foreign native і так далі.

Вибачте, але те, що ви пишете це емоційна брехня. Розберемо по тезах.

Затухне як це сталось свого часу із Delphi.

Java пережеве нас.

Не дивлячись на те, що на Java є доволі не мало сучасних технологічних рішень, Spring Boot мікро-сервіси де факто стандарт для claud native, нема Java програміста який не стикався би із Legacy.

А знаєте чому? Бо 8 років не вистачило інвестувати у те, щоб просто перейти від JDK 8 до JDK 17 (LTS), а там вже й до JDK 23. Я бачив такі компанії для яких навіть супер-круті бенчамарки показували, що перехід на нову JDK дасть 2-4х приросту продуктивності. Я вже не кажу про фактичне використання нового функціоналу.

Не дивлячись на те, що технологія Java досі актуальна, якщо використовувати сучасні фреймверки, Oracle в вочевидь фінансово не тягне розробку і розвиток технології.

Oracle вкладається в проекти OpenJDK так як ніхто із інших компаній просто не може, навіть якщо зібратися гуртом (тут є візуальне підтвердження) dou.ua/forums/topic/40030.

Констатую факт, якщо нічого не зміниться, конкретно ті самі Google та VMWare разом із Red-Hat/IBM не почнуть активно контрибьютити в OpenJDK як вони анонсували, з технологією Java усе буде дуже погано.

Вони й не роблять нічого для OpenJDK. Усі сучасні проекти типу Amber, ZGC, Loom, Panama, Valhalla, Leyden — це ініціативи та код моїх колег по Java Platfrom Group.

сучасні тех стеки розроблені з метою підвищення продуктивності праці програміста.

Знов невірно, за продуктивність відповідає мова. У Java є хороший приклад — Project Amber. А все інше це підвищення продуктивності застосунку.

Це усе методи пошуку монетизації проекту, якій коштує силенну ресурсів та коштів і не виправдовується фінансово, тобто ключова проблема Sun Microsystems була фактично продана Oracle разом із технологією.

Знов мікс фактів і фантазій з емоційним забарвленням. Фактично, акції ORCL (NASDAQ) ростуть, кількість клієнтів росте. Продукт Java SE — один із найуспішніших у Oracle.

Ба більше того, ми працюємо над тим, щоб робити Java кращою мовою на ринку технологій, і й особливо на ринку cloud-native, та cloud-ready технологій, чого лише вартує новий сервіс для розробників Java Management Service! Разом із тим ми маємо такий стек, який не існує у жодній мові програмування:
* Oracle JDK (binary, container)
* GraalVM
* Java Advanced Management Console
* Java Management Service
та ще набір ентерпрайзних рішень для JDK 8.