Авжеж, авжеж, чому не на 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.

Контракт не є приватним, бо його ще й вимагає відділ фін.моніторингу банку. Та й у контракті EPAMу нема слів про те, що він приватний. Ба більше того, факт співпраці ще підтверджується тим, що є фінансові операції ініційові EPAM, тому тупо блокувати watchdog-компанії це тупо.

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

Почну з того, що з початком вересня я вийшов на бенчу і за 1,5 місяці мій РМ(ресурс-менеджер) не зробив мені жодної пропозиції щодо нового проекту і в середині жовтня мені повідомили, що мене скорочують(перекрутивши фідбек на свій лад, але про це не будемо, не хочу лити багато багнюки)

На протязі всього цього часу, я намагався додзвонитися до свого ейчара(єдиний мій прямий контакт з компанією, який мені залишили), але дуже скоро я зрозумів що мене просто морозять), тобто виконавши всі свої обов’язки перед компанією, згідно екзіт ріквесту, почався просто лютий, та сміхотворний мороз. Ейчар не взяв трубку ЖОДНОГО разу, відповідь в вайбері можна чекати ТИЖДЕНЬ, одного разу довелось звернутись навіть на гарячу лінію, щоб на мене звернули увагу

Ну так це ж EPAM, в них це нормально. Коли я йшов звідти, то мене просто поблокували звідусіль, а коли до них звернулася watchdog-компания для перевірки факту мого контракту із ними, то вони й їх поблокували.

Невже єпам скис?)) В кого які думки?

у деяких руснявих блогерів проходила інфа, що певні курси по QA, Python спонсорує EPAM Russia й після того їх винаймає... але ж EPAM буде й далі розказувати що «іх-там-нєт».

Усе добре написано, але векторний код наведений вище закладає одну велику похибку: 256-біт векторні операції доступні лише на amd64, arm64 вміє лише 128-біт (архітектура NEON). Але й є процесори що можуть в AVX2.0 (специфікація Intel), тобто 512-біт. Для цього треба використовувати VectorSpecies.Preferred для того, щоб JVM могла вибрати найоптимальніший розмір векторних операцій.

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

Terraform CDK також є декларативним, оскільки кінцевий стан — це маніфест, які TF потім деплоїть.

Pulumi також є декларативним. Кінцевий стан — це артефакт pulumi engine, який безпосередньо застосовується до cloud provider API.

Це дає вам кілька переваг з декларативної сторони:

* Є багато місць, де механізм графів Terraform в кінцевому підсумку не будується правильно, і вам доводиться запускати тераформу більше одного разу. У Pulumi немає такої проблеми, тому що ви можете з’єднати речі в ланцюжок в асинхронному циклі. Наприклад динамічні обʼєкти TF контент яких доступних лише після первинного деплою, такими ресурсами можуть бути мережеві маски або регіону, або новостворенної віртуальної мережі (VCN).

* Pulumi використовує мови як першокласний механізм авторства, де Terraform CDK трансполює компоненти, написані мовою, у проміжний стан. Мається наувазі, що TF CDK інтерполює граф написаний Java/Python/Go у проміжний стан, який вже після того виконується самим TF.

Ну й простіше сказати, що усі родинні проблеми TF наслідуються безпосередньо й TF CDK. Pulumi була ж створена із врахуванням тих проблем.

Найцікавіша части Terraform’у полягає у тому, що план деплойменту це JSON структура із певною ступінню залежностей одних ресурсів від інших. І коли приходить розуміння цього, то вже й HCL вчити не треба, достатньо вже знати Java, Python, JS, golang. Бо еволюцією Terraform є проект моїх знайомих — www.pulumi.com

Pulumi це справжній infrastructure-as-code, (бо якщо бути відвертим, то HCL — це мова моделювання), бо задача полягає у тому, щоб із використанням вже існуючих інструментів досягти результату. З технічної точки зору, Pulumi вміє конструктуювати структури які розуміє Terraform, бо задача стояла не створити щось нове, а взяти від терраформу найкраще — ядро деплойменту на основі JSON-структур.

виправив, дякую

«поїздка на WebSummit» — аж до сліз...

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

А от що точно можна зробити, так це upcall до Java не просто для виклику Java-методів, а за для видачі памʼяті. Тобто, ви викликаєту метод, який володіє копією, або керую глобальним станом MemorySession або SegmentAllocator, і роздавати памʼять таким чином, щоб вона уся була врахованною, наприклад:

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class NewMain {

    protected static SegmentAllocator allocator;
    static Linker linker;
    static MethodHandle mallocHandle;
    static {
        linker = Linker.nativeLinker();
        try {
             mallocHandle = MethodHandles.lookup().findStatic(NewMain.class, "malloc",
                    MethodType.methodType(MemoryAddress.class, long.class));
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    static MemoryAddress malloc(long bytes) {
        var newSegment = allocator.allocateArray(ValueLayout.JAVA_BYTE, bytes);
        return newSegment.address();
    }


    public static void main(String[] args) {
        try(var memorySession = MemorySession.openConfined()) {
            allocator = SegmentAllocator.newNativeArena(memorySession);

            var mallocUpcall = linker.upcallStub(
                    mallocHandle, 
                    FunctionDescriptor.of(ValueLayout.ADDRESS, ValueLayout.JAVA_LONG),
                    memorySession
            );
            
        }
    }

Java mallocUpcall є еквівалентом до void* (*mallocPtr)(size_t); у С.

Технічно, це дозволить створити наступний С код:

#include <stdio.h>
#include <stdlib.h>

void callback_function(void* (*mallocPtr)(size_t)) {
   float* floatValue = (*mallocPtr)(sizeof(float));
}

int main()
{
    void* (*mallocPtr)(size_t);
    mallocPtr = &malloc;
    void* mem = mallocPtr(10);
    free(mem);
    callback_function(mallocPtr);
    return 0;
}

Отже, викликавши callback_function із параметром, що вказує на Java-метод malloc ми можемо зробити так, що за виділення памʼяті буде відповідати лише JVM.

Від так, ключове питання — а чи варто рефакторити легасі на використання віртуальних потоків?

ні, бо віртуальні потоки сумісні із платформенними, єдине що треба змінити, це який саме використовується ExecutorService, ось тут (dou.ua/forums/topic/38676) я показую як саме створити ExecutorService щоб, виділялися віртуальні потоки під задачі замість платформенних.

Якщо ж у вашому легасі-коді ви явно викликали Thread::start, замість ExecutorService, то нажаль так, доведеться.

чи є невирішені проблеми легасі, які вирішаться рефакторингом, чи краще відкласти це питання на 2 роки та протестити на чужих помилках?

Наразі є лише одне питання — як жити із ThreadLocal. На заміну їм розробляються ExtentLocal як більш підходящя альтернатива для віртуальних потоків враховуючи їх потенційну масштабованість.

Доброго дня. Нема нового 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 міг по-перше ії обчислити, й оптимізувати. Чи вам цього недостаньо?