Доброго дня. Нема нового JNI й не буде. JDK пропонує альтернативний шлях реалізації нативного коду у Java за допомогою C ABI.

новий JNI частково зламав зворотню сумісність з існуючим кодом

Що саме і де зламалося, можете бути більш конкретним, бо починаючи із 9-ї версії не було введено жодних змін, які б були зворотньо-несумістні.

Наприклад будь який дебаг призводить до крешу

Будь який дебаг чого, у якому середовищі, за допомогою яких інструментів? Давайте більше контексту.

Коли прийде розуміння простого факту, що всі потоки є віртуальними окрім роботи вже на низькому рівні

так справа ж і йде про pthread, win32. JVM в свою чергу ж огортає системний (платформенний) поток, так що не всі потоки віртуальні.

Особисто я вважаю, що цю ідею треба розвивати й надалі,

Так ми й працюємо над цим, наступним є впровадження Structured Concurrency, Continuations та заміна ThreadLocal на ExtentLocal для віртуальних потоків (статтю про це я вже розробляю).

Чому так: абсолютна більшість потоків є дрібними.

Не потоків, а завдань (Runnable/Callable) які виконуються у цих потоках. Отже, одну й ту ж задачу, можна розбити на декілька continuation-блоків розмежувавши їх по блокуючих викликах.

Якщо важливо — тоді варто використовувати механізми явної паралелізації...

не параллелізації, а синхронізації із резервуванням потоку-носія, наприклад, коли виконується нативний C-код з JNI, або через MethodHandle у Panama — у тих випадках, коли вклай важливо отримати той же стек потоку, а не отримання нового.

дякую =)

Заждіть, але ж ви можете це зробити й зараз, але треба робити усе константами (static final), щоб C2 міг по-перше ії обчислити, й оптимізувати. Чи вам цього недостаньо?

Так, саме він =)

Я колись виступав на DenverJUG підчас ковіду. Я думаю, що він зрозуміє.

Наприклад, імутабельність за умовчанням.

Навпаки, є простий спосіб зробити класс іммутабельним, а от зробити його мутабельним із іммутабельного призведе до породження багатьох екземплярів одного классу, та доведеться робити де-референсерінг дуже частно (те, що робить Kotlin, наприклад із своїми фінальними класами).

Я ж і кажу що для минулого сторіччя досить непогано. Але хотілося б, щоб такого класу помилок взагалі не було.

призведе до перевикористання памʼяті, бо NULL лише один, а замість нього доведеться створювати екземпляри класів для того, щоб уникнути NPE або явний перевірок на NULL у компанії із аннотаціями.

Передавайте мої вітання Метту Рейблу ;)

Вона чітко й ясно показує фактичний вклад компаній у розвиток Java, а не створення власних дистрибутивів :wink:. Що він не показує, нажаль — персональні внески у Java від релізу до релізу. Але, якщо зовсім просто, то цей графік показує хто створю майбутне Java.

так

null safety

нема адекватного у жодній мові програмування, але в Java є функціонал класу Objects типу docs.oracle.com/...​ts.html#requireNonNull(T

mutable а що immutable

взагалі є, наприклад у коллекціях (Set.of, List.of). Щодо обʼєктів, то є Java record — по-замовчанню іммутабільний обʼєкт. То що ще треба?

Є жор пам’яті

Вибачте мене, але без конкретики важко спростувати, чи підтримати вашу тезу.

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

А що саме вас не влаштовує наразі? Дуже цікаво, якщо честно.

Так а хто вам заважає взяти у руки nmap, завести врасту вітруалку на кацапському VPS (щоб уникнути гео-теггінгу) та почати сканити потенційні мережі? Що заважає повивчати kali-linux збірку для мережевих атак та тримати під рукою базу CVE/CWE на випадок вже існуючих вразливостей та експлойтів до них.

Ну а що стосується ддос — так не це складно, запустив 2-3 процеси і воно фігачить. Але якщо в вас є потужності, що будуть генерувати гігабіти трафіку за секунду, то ви можете буде набагато кориснішим, а ніж купка людей з каналу.

Я так і сказав: десь вас таки навчають говорити незрозумілою мовою. Багато тексту можете. Але відповісти на просте питання ЩО ЦЕ ТАКЕ — майже жоден технічний райтер не здатен. Можу лише припустити, що тих, хто може вийти за рамки паралельного світу бюрократії — згодовують крокодилам.

Ну, якщо ви не переходили по посиланням і не читали текст, то надам відповіть тут, стисло: jextract — інструмент кодогенерації інфраструктурного коду, який використовується як для виклику нативних функцій (downcall), так і для зворотньої процедури (upcall). До інфраструктурного коду входять наступні компоненти: MethodHandle, VarHandle, Linker, SymbolLookup, FunctionDescriptor.

Хто отримає вигоду і що буде продуктом.

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

це просто намагання транслювати нативний код у код на Java, і виконувати вже в рамках JVM?

ніякої трансляції нема, є реалізація концпету ABI.

Тобто, всі вигоди роботи саме нативного коду втрачаються, нативний код не працює у нативному середовищі взагалі?

Знов дивне питання. Результат роботи інструменту — згенеровані Java класи, структура яких відповідає С-хедер файлу відносно якого ці класи генеруються.

І що є його первинним продуктом для перетворення — вже готовий нативний код, чи який-сь сурогат, чи первинний код на С чи CPP?

Основний ресурс для jextract — С-хедер файл. Далі, як кажуть, дивись C ABI документацію, бо цей концепт працює в усіх мовах програмування написаних на С: C++, Rust, Golang, Node, Python, Java і так далі.

З JNI все більш-менш зрозуміло, це цілком нативний код, що виконується в нативному середовищі

Не вірно. JNI лише складається з нативного коду, Java code та недоступного функціоналу зашитого у JVM який й відповідає за поєднання скомпільованої shared-бібліотеки та рантаймом.

А от що таке Panama?

Project Panama — ініціатива у межах OpenJDK метою якою є концептуально якісно змінити підход до роботи із нативним кодом. У рамках цього проекту реалізується два блоки нових API: Foreign Function & Memory API (реалізація C ABI та керування пам’яттю типу malloc/realloc/calloc) та великого блоку Vectors API (SIMD).

Просто ще один JNI? Чи обгортка для існуючого JNI?

Ніт, ніт і ще раз ніт. Не може бути «ще одного JNI», не може бути й обгортки навкого JNI. Foreign Function & Memory API (частиною якого є jextract) це реалізація концепту C ABI. Якщо в вас виникають питання що таке JNI і чому воно не C ABI, то це стаття не проце.

0) Для чого взагалі створили інструмент. І не 1-2 строчки бла-бла-бла, а реально потрібна стаття про типові задачі, вирішувані цим інструментом. Із коротесеньким поясненням, чому не підійшли інші (чи підійшли погано), акцент на слові «чому», і що сталося після. Важливо: це треба пояснювати в картинках, тобто інфографікою, яка дає можливість візуально побачити РОЗМІРИ роботи (наприклад, пропорційно витраченому машиною часу, чи пропорційно реального часу написання типових програм, чи те і інше).
Чому так: ти пишеш для людей. Якщо ти втратив ланку розуміння нішевого інструменту, все інше що в тебе написано — просто мотлох.

Відповім вам як Java-розробник Java-рознобнику: відповідь на це питання полягає в нерозумінні специфіки роботи із нативним кодом. Досить давно, ще починаючи із JDK 1.2, існувала можливість створювати так званий JNI — багатокомпоненту структуру яка складається із C-бібліотеки, хедеру до неї та native Java методів. Проблема полягала у тому, що фокус розробки зсувався у сторону С, ніж Java. Наразі ж, увесь Project Panama переслідує мету залишити розробку у площині Java, ніж C/C++ використовуючи C ABI.

На скільки це краще — покаже час, але сфера застосування вже відома, є дуже багато проектів які прагнуть позбутися JNI, той же Hadoop, Spark, Cassandra. Також є AI/ML фрейморки в яких є C API, то ж створення доступу до них буде ще просішим та повністью сфокусованим у рантаймі JVM.

Гірше можна зробити тільки знявши відео для ютубчика, ще гірше — виступ на конференції. Бо це по суті зводиться до «дивіться які я знаю розумні слова».

Як скажете, ще ніхто не скаржився на мої доповіді та їх якість.

-1) Юридична частина. Що із цим можна робити, кому за що треба платити, які обмеження матиме кінцевий продукт. Бо мати справу із Ораклом — сам розумієш, бомба сповільненої дії, яка може похоронити увесь проект через якісь пару строчок коду. Оракл має ну дуже неоднозначну репутацію стосовно юридичного лайна, яке закладається у технології розробки. Не в тому проблема, що щось є платним, щось халявним, але в тому, що готовий продукт стає залежним від трактування невідомо якої глибини юридичного болота в невідомо якій юрисдикції.

І знов, ваше питання базується на нерозумінні принципів ліцензування Java. Дякую за це, є ще одна тема для статті на DOU. Надам коротку відповідь — інструмент безкоштовний, як і сама OpenJDK.

З жабою все ну дууже неоднозначно — жаба сама по собі продукт, який потребує (чи не потребує) постійного оновлення та затикання дір

Якийсь у вас дивний досвід, якщо честно.

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

Ваше питання дещо натякає на нерозуміння концепції кодогенерації. Ви jextract запускаєте ЛИШЕ ОДИН РАЗ для генерації класів і все, вам не треба мати цей інструмент під рукою увесь час, ба більше того, в рантаймі вам цей інструмент не потрібний.

1) Хто врешті решт менеджить пам′ять, JVM чи інший збирач сміття? Як це виглядає у життєвому циклі?

Про це як раз наступна стаття, яка вийде згодом.

2) Своп. Що буде, коли процес залітає у своп, нехай і невеличкою частиною? Це взагалі-то нормальне явище для процесів із довгим життєвим циклом. Як саме менеджити рідко використовувані об′єкти даних, щоб вони могли безпечно потрапляти у своп із тим щоб їх не витягувало звідти при першому ліпшому проході збирача сміття? Можливо відповідь криється у першому питанні — який процес взагалі керує пам′яттю, чи їх кілька окремих?

Використовуючи нативну пам’ять у JVM ви не потрапите до свопу жодним чином. Якщо пам’яті не можливо виділити скільки треба, то JVM вас про це сповістить через ексепшн.

3) Задача дистрибуції софту. Чи є вже типові моделі, якими саме можуть бути продукти на цьому інструменті? В плані компонентів — як це виглядатиме із точки зору кінцевого отримувача, в тому числі які процеси апдейтів?

Це гарне питання і на нього в мене є відповідь, ось вам посилання на референсний проект github.com/...​-Java-API/libopencv-clang — там є відповіді на всі ващі питання!

PS. Чи продукт є халявним, чи таки в нього є цінник за використання? Чи планується? Бо інструмент виглядає досить нішевим, я б скоріше зрозумів його комерційну розробку, тобто із витратами на підтримку. Чи є кілька моделей/версій/ліцензій? Краще коротко та зрозумілою мовою.

Безкоштовний, перша збірка доступна тут jdk.java.net/jextract

І тут справді постає питання до ІТ-ассоціації яка божилася, що вони от-то «продавлять» мінцифри та мо щодо процедури бронювання. Ситуація так, що ситуація не змінюється і ми бачимо, що держава лише закручує гайки із оцією постановою КМУ щодо «відряджень», і я не те щоб панікую, але я не бачу зацікавленості держави в адекватних рішеннях, нажаль.

Я вимушений констатувати, що автор не досить добре розуміється на термінології, що також викликає сумніви щодо якості тесту. Отже,

найпопулярніших реалізацій JVM

йдемо до Wiki і дивимося які існують JVM en.wikipedia.org/...​_of_Java_virtual_machines. Далі, наведені приклади це ДИСТРИБУЦІЯ проекту OpenJDK. Я би міг пройтися по кожному лінку, але ось навіть доки по Corretto говорять, що воно НЕ JVM: aws.amazon.com/...​red-posts.sort-order=desc

Тому, я би рекомендував виправити статтю бо не існую а ні «Опенсорсна реалізація JDK», а ні «Опенсорсна JDK» і це легко довести лише подивившись з чого складається JDK простою командою:
java --list-modules

Далі, існую проект OpenJDK, існую декілька дистибуцій OpenJDK від Oracle, Azul, AWS, Zulu, etc. (різниця полягає лише у тому із ким ви підписуєте контракт на підтримку). Окремо існує «стандрат JVM», у складі проекту OpenJDK є HotSpotVM розроблена Sun і якою володіє Oracle, цю JVM використовують майже усі наведені включно із GraalVM CE/EE.

який тестує всі основні аспекти продуктивності JVM, окрім, хіба що, GC

 — після цього статтю можна далі й не читати, бо тест не враховую а ні AppCDS, а ні ZGC. Бо перший дає змогу виправляти проблему холодного старту, а новий GC — паузи менші за 10мс. Ба більше гото, якщо почитати спеціфікації на кожну вендор-специфічну дистрибуцію OpenJDK, то можна побачити, що вони відрізняються у конфігурації та типу GC (HotSportVM — G1, Azul — C4, у RedHat — Shenandoah GC) , тюнінгу та реалізації JIT-компілятору, наприклад Azul використовую Falcom LLMV, а Oracle OpenJDK — C2, у той час як GraalVM — взагалі використовую свій компілятор.

всі JVM на базі HotSpot

 — знову некорректне твердження яке потребує виправлення, бо HotSpotVM і є імплементацією JVM.

Далі, тест JNI не показовий взагалі, бо ця технологія застара і не оновлювалася дуже довгий час (не дивно, що з того часу вже були створені технлогіі типу JNA, JavaCPP). Треба робити тест на основі Foreign Function & Memory API (Project Panama) який базується на константних/статичних та динамічних визначеннях MethodHandle.

Далі, сам бенчмарк не є показовим взагалі, бо не використовую нативні інструменти для бенчмаркінгу JVM — github.com/...​icrobenchmark-harness-jmh.

Отже, висновок. Порівняння дистибуцій OpenJDK робилося на «якомусь» linux-сервері: а ні типу процессору, а ні тип диску, а ні кількість наявної оперативної пам’яті. Але це дрібниці. Сам бенчмарк написаний на Kotlin, тобно існє додатковий шар оверхеду при компіляції у байткод. На скільки це еффективно? Треба дивитися сам байткод і порівнювати із оригіналом написаним на Java. Навіть у такій формі тест не є показовим, бо усі OpenJDK тестувалися не у рівних умовах.

Є одне велике АЛЕ розміром із цілий довоєнний Харків...

Подивіться пости навіть тут, на DOU, щодо бронювань. Законодавства яке б дозволяло бронювати людей без мобілізаційного завдання просто не існує. Ба більше того, нема законодавства яке б дозволило бронювати ФОПів або гіг-контракторів.

Отже, що таке «бронювання айтівців» і чи існує воно? Відповідь, я думаю, ви зрозумієте самі.

Я б ще зазначив, є ще інша сторона питання «їхати, залишатися» не обмежується питанням закордону. Глобальна внутрішня міграція переформатує Україну.

Я з Харкова, жодного дня не думав про еміграцію, навіть про переїзд по Україні мене не цікавив. Але 24 лютого ми прокинулися у новій реальності... як би я не вірив у ЗСУ, але давайте будемо відверті — війна не закінчиться, а ні завтра, а ні за 2 роки. Ми ж всі бачимо пости Подоляка, заклики інших топ-посадовців надати нам зброю зараз, а не за пів-року-рік. Ми, волонтери, бачимо, що запити від військових приходять типу від гуми на автівки, форми, трусів/шкарпеток до, хай йому грець, зброї типу AR-15 та снайперських гвинтівок для ССО не кажучи вже про тепловізори, дрони, глушилки, генератори й так далі, тобто, запеспечення знаходиться на низькому рівні.

Це все наводить на думку, що нас чекає корейський варіант від Харкова до Мелітополя. А це означає, що нинішні вимушені переселенці стануть, вже мешканцями інших міст від Вінниці до Львова. Бо, наприклад, в мене в Харкові більше нема житла (не рахуючи заморожену недобудову), із приходом зими моїй сім‘ї доведеться покину їхні будинки, бо є розуміння, що в постраждалих районах Салтівки та Горизонту не буде опалення. Я це все до того пишу, що таких історій як моя — мільйони, а це значить, що усі міста на лінії фронту не залишаться у спокої, бо ми ж хочемо ізраїльський варіант.

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

ThreadLocals нікуди не ділися, віртуальні потоки теж мають їх. Дивіться на віртуальні потоки як на звичайні потоки, з точки зору програмування нема жодної різниці між платформеним та віртуальним потоком, а то як вони виконуються це відповідальність JVM.