The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск Java SE 24 и OpenJDK 24

19.03.2025 19:17

После шести месяцев разработки компания Oracle опубликовала платформу Java SE 24 (Java Platform, Standard Edition 24), в качестве эталонной реализации которой используется открытый проект OpenJDK. За исключением удаления некоторых устаревших возможностей в Java SE 24 сохранена обратная совместимость с прошлыми выпусками платформы Java - большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 24 (JDK, JRE и Server JRE) подготовлены для Linux (x86_64, AArch64), Windows (x86_64) и macOS (x86_64, AArch64). Разработанная в рамках проекта OpenJDK эталонная реализация Java SE 24 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами.

Java SE 24 отнесён к категории выпусков с обычным сроком поддержки, обновления для которого будут выпускаться до следующего релиза. В качестве ветки с длительным сроком поддержки (LTS) следует использовать Java SE 21 или Java SE 17, обновления для которых будут выпускаться до 2031 и 2029 годов соответственно (общедоступные - до 2028 и 2026 годов). Расширенная поддержка LTS-ветки Java SE 8 продлится до 2030 года, а Java SE 11 - до 2032 года. Следующим LTS-релизом станет осенний выпуск Java SE 25.

Среди предложенных в Java SE 24 новшеств:

  • Предложен экспериментальный генеративный режим работы сборщика мусора Shenandoah, при котором раздельно обрабатываются старые и недавно созданные объекты для повышения эффективности очистки объектов с небольшим временем жизни. Новый режим обеспечивает более предсказуемую пропускную способность, устойчивость к изменению нагрузки и снижение потребления памяти при сборке мусора. Планировщик Shenandoah нацелен на сокращение времени остановок во время сборки мусора за счёт проведения большего объёма работ параллельно с выполнением Java-приложений.
  • В HotSpot JVM реализована экспериментальная поддержка компактных заголовков объектов, размер которых на 64-разрядных системах уменьшен с 96 до 64 бит (с 12 до 8 байт). Уменьшение размера заголовков позволяет сократить размер кучи и повысить эффективность работы кэша.
  • В сборщике мусора G1 упрощена реализация барьеров, отслеживающих доступ приложения к памяти. В новой версии операции расширения барьеров перенесены на более поздний этап компиляции в C2 JIT. Проведённые тесты показывают, что подобный перенос позволяет снизить накладные расходы в JIT-компиляторе C2 на 10-20% в зависимости от приложения.
  • Добавлен API для использования криптографических функций формирования ключа (KDF, key derivation function), позволяющих сформировать дополнительные ключи необходимой длины на основе секретного ключа (например, пароля) и произвольного набора данных. KDF API пока имеет статус предварительного (preview).
  • Добавлена возможность упреждающей (Ahead-of-Time) загрузки и компоновки классов. Изменение позволяет ускорить запуск HotSpot JVM за счёт предоставления используемых в приложении классов в уже загруженном и скомпонованном состоянии. Во время первого запуска приложения состояние всех классов сбрасывается в кэш и при последующих запусках используется для ускорения загрузки.
  • Добавлен API Class-File для разбора, генерации и преобразования файлов с классами Java.

    
       ClassFile cf = ClassFile.of();
       ClassModel classModel = cf.parse(bytes);
       byte[] newBytes = cf.build(classModel.thisClass().asSymbol(),
            classBuilder -> {
                for (ClassElement ce : classModel) {
                    if (!(ce instanceof MethodModel mm
                            && mm.methodName().stringValue().startsWith("debug"))) {
                        classBuilder.with(ce);
                    }
                }
            });
    
    
  • Добавлен расширенный API Stream, поддерживающий определение собственных промежуточных операций, которые могут оказаться полезны в случаях, когда существующих встроенных промежуточных операций недостаточно для желаемого преобразования данных. Собственные обработчики подключаются при помощи новой промежуточной операции Stream::gather(Gatherer), которая обрабатывает элементы потока, применяя к ним заданный пользователем обработчик.
    
       jshell> Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList()
       $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
    
  • Предложена четвёртая предварительная реализация ограниченных значений (Scoped Values), позволяющих совместно использовать неизменяемые данные в потоках и эффективно обмениваться данными между дочерними потоками (значения наследуются). Scoped Values развиваются для замены механизма переменных локальных к потоку (thread-local variables) и более эффективны при использовании очень большого числа виртуальных потоков (тысячи и миллионы потоков). Главное отличие Scoped Values от переменных локальных к потоку в том, что первые записываются один раз, в дальнейшем не могут быть изменены и остаются доступны только на время выполнения потока.
  • В механизмы сопоставления с образцом добавлена предварительная поддержка использования примитивных типов (int, byte, char и другие базовые типы, не являющиеся объектами) во всех видах шаблонов, в операторе "instanceof" и в блоках "switch".
    
       switch (x.getStatus()) {
           case 0 -> "okay";
           case 1 -> "warning";
           case 2 -> "error";
           case int i -> "unknown status: " + i;
       }
       if (i instanceof byte b) {
        ... b ...
       }
    
  • Предложена девятая предварительная реализация API Vector, предоставляющего функции для векторных вычислений, которые выполняются с использованием векторных инструкций процессоров x86_64 и AArch64 и позволяют одновременно применить операции сразу к нескольким значениям (SIMD). В отличие от предоставляемых в JIT-компиляторе HotSpot возможностей по автовекторизации скалярных операций, новый API даёт возможность явно управлять векторизацией для параллельной обработки данных.
  • Реализована поддержка синхронизации виртуальных потоков без их прикрепления (pinning) к потокам, связанным с платформой. Виртуальные потоки в синхронизированном методе или выражении в состоянии блокировки теперь освобождают свой платформенный поток, позволяя другим виртуальным потокам использовать его, что значительно увеличивает количество доступных виртуальных потоков и улучшает масштабируемость приложений, использующих многопоточность.
  • Добавлен третий предварительный вариант возможности, разрешающей указание в конструкторах выражений перед вызовом super(...), используемого для явного вызова конструктора родительского класса из конструктора наследуемого класса, если эти выражения не ссылаются на создаваемый конструктором экземпляр.
    
       class Outer {
           void hello() {
               System.out.println("Hello");
           }
           class Inner {
               Inner() {
                   hello();
                   super();
               }
           }
       }
    
  • В утилите jlink реализована поддержка создания образов run-time без использования файлов JMOD, что позволяет примерно на 25% сократить размер JDK.
  • Добавлен второй предварительный вариант использования одного выражения "import module M" для импорта сразу всех пакетов, экспортируемых указанным модулем. Изменение существенно упрощает повторное использование модульных библиотек, позволяя подключать библиотеки и классы без определения их места в иерархии пакетов. Например, указание "import module java.base" приведёт к импорту всех 54 пакетов, входящих в модуль java.base, которые ранее потребовалось бы упоминать по-отдельности ("import java.io.*", "import java.util.*" и т.п.).
  • Добавлена четвёртая предварительная реализация неявно объявленных классов и безымянных экземпляров метода "main", в которых можно обойтись без объявлений public/static, передачи массива аргументов и прочих сущностей, связанных с объявлением класса.
    
       // было
       public class HelloWorld {
         public static void main(String[] args) {
           System.out.println("Hello world!");
         }
       }
    
       // теперь можно
       void main() {
           System.out.println("Hello, World!");
       }
    
  • Предложен для тестирования четвёртый предварительный вариант API для cтруктурированного параллелизма (Structured Concurrency), упрощающего разработку многопоточных приложений за счёт обработки нескольких задач, выполняемых в разных потоках, как единого блока.
  • В API KeyPairGenerator, Signature и KeyFactory добавлена поддержка алгоритмов ML-KEM (CRYSTALS-Kyber) и ML-DSA (CRYSTALS-Dilithium), стандартизированных Национальным институтом стандартов и технологий США (NIST) и стойких к подбору на квантовом компьютере. Данные алгоритмы используют методы криптографии, основанные на решении задач теории решёток, время решения которых не отличается на обычных и квантовых компьютерах.
  • В сборщике мусора ZGC удалена поддержка не генеративного режима работы, не разделяющего обработку "старых" и "молодых" объектов. Начиная с Java SE 23 генеративный режим ZGC применяется по умолчанию.
  • Добавлен вывод предупреждений об использовании API JNI (Java Native Interface) и FFM (Foreign Function & Memory) с целью подготовки разработчиков к ограничению доступа к данным API из-за включения в одном из будущих выпусков режима обеспечения целостности, по умолчанию запрещающего взаимодействие с нативным кодом.
  • Включён вывод предупреждения при использовании методов доступа к внешней памяти (вне JVM), предоставляемых классом sun.misc.Unsafe. Для обращения к памяти вне кучи (off-heap) и взаимодействия с внешними кодом рекомендуется использовать API VarHandle. В прошлом выпуске поддержка sun.misc.Unsafe была объявлена устаревшей.
  • Отключён Security Manager, который давно потерял актуальность и оказался невостребованным после прекращения поддержки браузерного плагина. Security Manager был переведён в разряд устаревших в Java 17. В одном из следующих выпусков планируется полностью удалить код Security Manager.
  • Удалён код для поддержки 32-разрядной платформы ОС Windows на системах x86. Объявлен устаревшим и запланирован к удалению порт Java для 32-разрядных систем x86 (будет прекращена поддержка Linux на 32-разрядных системах x86).

Дополнительно можно отметить публикацию обновления платформы для создания приложений с графическим интерфейсом JavaFX 24 и новый выпуск универсальной виртуальной машины GraalVM, поддерживающей запуск приложений на JavaScript (Node.js), Python, Ruby, R, любых языках для JVM (Java, Scala, Clojure, Kotlin) и языках, для которых может формироваться биткод LLVM (C, C++, Rust). Кроме поддержки JDK 24 в новой версии GraalVM проведены оптимизации для задач, связанных с машинным обучением, улучшена поддержка компиляции Java-байткода в машинный код, добавлен механизм SkipFlow для сокращения размера исполняемых файлов и уменьшения времени компиляции.

  1. Главная ссылка к новости (https://mail.openjdk.org/piper...)
  2. OpenNews: Выпуск Java SE 23 и OpenJDK 23
  3. OpenNews: Выпуск платформы Java SE 22 и открытой эталонной реализации OpenJDK 22
  4. OpenNews: Треть Java-проектов на базе библиотеки Log4j продолжают использовать уязвимые версии
  5. OpenNews: Выпуск Java SE 21
  6. OpenNews: Компания Oracle представила универсальную виртуальную машину GraalVM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62914-java
Ключевые слова: java, jdk, graalvm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (90) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, Аноним (4), 20:05, 19/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –17 +/
    Как сейчас у джавы дела с производительностью? Только жиреет с каждым релизом?
     
     
  • 2.16, _hide_ (ok), 21:09, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +9 +/
    У самой Жавы с производительностью очень хорошо ещё со времен телефонов с 32КБ памяти. А вот у погромистов на ней не всегда получается избегать узких мест (ведь прикольно же создавать 10Е6 объектов в секунду?).
     
     
  • 3.30, Анон1110м (?), 23:09, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как–то читал жалобы на то что JVM это сильный тормоз для тех самых телефонов с 32КБ (и около того) памяти. Вместо полезных вычислений ресурсы расходуются на JVM что не даёт им раскрытьяс полностью. Жалобы года эдак 2005.
     
     
  • 4.36, ZloySergant (ok), 01:10, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Балаболы. Всё нормално работало.
     
     
  • 5.38, cheburnator9000 (ok), 02:36, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это потому что JavaME был оптимизированным рантаймом под конкретные платформы и конкретные задачи, ничего лишнего там не было. Сейчас же в памяти у Java лежит столько всего что компилируемые ЯП в ужасе шарахаются.

    Тот же C# умеет в нативную компиляцию. Там сейчас исключение это не полностью рефлексия поддерживается в таком режиме (та часть, что в рантайме выполняется). В итоге скомпилированная программа вполне конкурирует по производительности с плюсами. А как у Java в этом плане? Подозреваю что очень плохо.

     
     
  • 6.42, Alex (??), 05:37, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    То есть что такое GraalVM ты в принципе не знаешь...
     
     
  • 7.45, Аноним (45), 09:24, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не существует ни граалей, ни серебрянных пуль
     
  • 7.54, Аноним (54), 12:37, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если быть до конца честным, то Graal - это все таки отдельный продукт (как и продукты-предшественники, в том числе и отечественной разработки.

    Тогда как "нативная компиляция" в C# - фича языка и фреймворка.

    ПС. хотя и то и другое изврат - как сами языки и концепции vm, так и возможность "типа нативной" компиляции. Мне больше импонирует нормальная нативная компиляция, другое дело, что С++ устарел конечно же.

     
     
  • 8.98, Аноним (98), 06:27, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я вам больше скажу Даже математические теоремы устарели, и для обеспечения безо... текст свёрнут, показать
     
     
  • 9.102, Аноним (-), 17:49, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А где в дыряшках C C математические теоремы Там даже нет детерминированности ... текст свёрнут, показать
     
     
  • 10.106, Аноним (98), 20:12, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так я и говорю, что раст современнее, моднее, научнее, поэтому мы и пабидим цепл... текст свёрнут, показать
     
  • 2.21, Аноним (21), 21:29, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Всё отлично, как и всегда. Лучший язык для очень больших проектов, пишущихся в больших командах. Но для домашних и соло-проектов java является оверкиллом, да.
     
     
  • 3.71, Аноним (-), 15:33, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вон кто-то ущемился и влепил тебе диз 😆 но в целом прав на 100%
     
  • 2.29, Аноним (29), 22:52, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Как сейчас у джавы дела с производительностью

    Производительность? Они вектора на третьем десятке версий до сих пор рожают.

    > девятая предварительная реализация API Vector

     
  • 2.33, Аноним (33), 00:47, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У явы проблемы с производительностью были только в начале, на самой заре, а в дальнейшем всё стало просто отлично. А вот памяти она всегда жрала много.
     
     
  • 3.35, Аноним (35), 00:59, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Помнится, были легковесные виртуальные машины для неё.
     
     
  • 4.90, iZEN (ok), 19:27, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Помнится, были легковесные виртуальные машины для неё.

    IBM J9 JVM, например, отдельно устанавливалась, запускалась и работала на КПК HP iPAQ hx4700 с апплетами и приложениями Java/JavaME.

     
  • 2.115, Аноним (115), 11:04, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Как сейчас у джавы дела с производительностью?

    Если сабж не бесплатный (а он не бесплатный), обсуждать можно только абонентскую плату в месяц на одного пользователя.
    > Только жиреет с каждым релизом?

    От вырученных денег? Да.

     

  • 1.5, Аноним (5), 20:08, 19/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Насколько велики задержки создаваемые сборщиком мусора? Неужели все настолько плохо?
     
     
  • 2.7, funny.falcon (?), 20:18, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Насколько плохо? Для каких задач? Какого сборщика?

    Видите, сколько в вашем холиварном вбросе неизвестных. Очевидно, ответить вам не представляется возможным.

     
     
  • 3.12, Аноним (5), 20:54, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Полагаю, ограничения в сфере задач и будут определяться задержками. Не вброса ради...
     
  • 2.19, Аноним (35), 21:23, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, некоторые Real-time приложухи на ней даже пишут, только сделать это непросто.
     

  • 1.10, penetrator (?), 20:46, 19/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Что Linq так и не завезли? Почему стримы нельзя было сделать сразу нормальными? ))

    Чет Java ерундой занимается, но все равно всяко лучше, чем костыль вроде Kotlin  

     
     
  • 2.20, Аноним (20), 21:23, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всмысле костыль? Нормальный язык.
     
     
  • 3.26, penetrator (?), 22:09, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    что в нем нормального? джава на стероидах, все новые фичи сделанные через задницу

    даже джава лучше и прозрачнее, с развитием Java котлин станет не нужным

     
     
  • 4.27, Аноним (20), 22:30, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > все новые фичи сделанные через задницу

    Конкретно, что не так?

    Nullsafety - хорошая вещь. Функции-строители для создания своего DSL - вообще мега вещь. Да и в целом котлин выглядит красивше и лаконичнее джавы.

    Вы хоть сами то на нём писали? И я имею в виду не в течении 30 минут хелоуворлд создать, а по хорошему в течении нескольких месяцев.

     
     
  • 5.31, Аноним (31), 23:41, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Конкретно, что не так?

    1. Очередная прослойка поверх JVM, добавляющая ненужные зависимости и замедляющая компиляцию и сборку.
    2. Не освобождает от необходимости знать Java, ибо 99% библиотек, с которыми взаимодействует Котлин - написаны на Java. А если я уже знаю Java, нахрен мне знать еще Kotlin?

    >Nullsafety - хорошая вещь

    В Java тоже скоро завезут:

    String! a = "abc"; // OK
    String! a = null; // NUllPointerException

     
     
  • 6.43, User (??), 07:42, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ага А C - очередная прослойка поверх llvm, добавляющая ненужные зависимости и ... большой текст свёрнут, показать
     
  • 5.32, да ты (-), 00:30, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Nullsafety

    Очень переоценена. Изначально пришла вообще из фп, где любой null в цепочке вызовов лапши функций отправлял в счасливую отладку на века. Фпшники выкрутились сделав null частью возвращаемого типа. В императивных языках так делать не нужно — есть нормальный отладчик, можно написать явную проверку на null где угодно и обработать её. Nullsafety это решение проблемы существующей только в мозгах изучавших computer science по скипу и подхвативших ФП головного мозга.

     
     
  • 6.34, Аноним (33), 00:54, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > В императивных языках так делать не нужно — ... можно написать явную проверку на null где угодно и обработать её

    "Не пиши программы с ошибками, пиши без ошибок". Ну и т.д. из серии про Настоящих Программистов.

    А вообще за годА задолбали ошибки нуллпоинтерэксепшн из-за того что в очередной стопицотый раз кто-то где-то что-то не проверил.

     
     
  • 7.44, Анониматор (?), 08:11, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Приходилось эксплуатировать кучу софта написанного на Java, да и сейчас приходится. В трассировке ошибок всех этих прог угадай что? Да, на все 100% null pointer exception
     
     
  • 8.94, iZEN (ok), 23:19, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    На сишечке на это в своё время забили болт и возложили всю ответственность с по... текст свёрнут, показать
     
     
  • 9.116, Jh (?), 13:25, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    С придумали когда ресурсов у компьютера было с гулькин клюв и программисты кажды... текст свёрнут, показать
     
     
  • 10.118, iZEN (ok), 17:09, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    LISP придумали раньше ... текст свёрнут, показать
     
  • 8.99, Программист (?), 10:42, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем нам проверять ввод В рантайме бросит 8212 увидим в логе и поправим ... текст свёрнут, показать
     
  • 6.59, penetrator (?), 13:46, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    согласен, в шарпе отключаю к черту

     
  • 6.113, Илья (??), 10:16, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Nullsafety это решение проблемы существующей только в мозгах изучавших computer science по скипу и подхвативших ФП головного мозга.

    Не знаю как в java, но в с# тебя компилятор будет лицом в грязь тыкать, пока ты не расставишь проверки на null в необходимых местах. Котлин - мусор

     

  • 1.17, Аноним (21), 21:21, 19/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сижу на 8 версии и не вижу никакого смысла её менять. Java это всё же в первую очередь про стабильность.
     
     
  • 2.50, Аноним (50), 12:02, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну значит работаешь в такой компании, где безопасников нет вообще или они заняты не тем. В любой приличной конторе после выхода новой LTS версии всем командам закидывается техдолг по переводу своих сервисов на эту версию. В первую очередь потому что CVE пофикшены, бонусом идёт производительность.
     
     
  • 3.70, Аноним (-), 15:32, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю как у него, но в нашей корпорации федерального значения с тысячями сотрудников (без преувеличения), тоже до сих пор 8 версия. Я не java программист и работаю в другой области, поэтому всех одробностей не знаю, может это расширенная поддержка какая-то, но то, что используется 8 версия - это факт.
     
  • 3.76, Аноним (29), 16:13, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > CVE пофикшены

    Тебе не кажется странным, что уже овер 20 версий - а CVE всё фиксят и фиксят... Какую бы версию ты ни выбрал - всегда будут непофикшеные баги. А учитывая, что сейчас разработками занимается поколение Y (в т.ч. миллениалы и ...шники), я предпочитаю SUN Java HotSpot Server 6.

     
  • 3.77, _hide_ (ok), 16:13, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Безопасность? Да под старую версию всё явы, связанное пакетными менеджерами и зависимостями не то что собрать, даже достать невозможно.

    А вот миграция под 10 Томкат задача невыполнимая!

     
  • 3.104, zionist (ok), 19:44, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > В любой приличной конторе после выхода новой LTS версии всем командам закидывается техдолг по переводу своих сервисов на эту версию. В первую очередь потому что CVE пофикшены, бонусом идёт производительность.

    Глупость какая-то. Всегда есть несколько LTS версий, которые продолжают поддерживаться и обновляться. Кроме того примерно с 9-й Джавы каждый переход на новую мажорную версию приводит к большим проблемам.

     

  • 1.24, abi (?), 21:42, 19/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А Котлин не в мобильной среде используется? Давно про него не слышно, хотя раньше были заявления, мол, начинать новые проекты на Java, если есть готлин смысла не имеет
     
     
  • 2.25, Аноним (20), 22:01, 19/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Используется конечно. Помню некоторые компании его на серверах стали использовать.
     
  • 2.37, мяв (?), 01:29, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    да. большая часть фдройда - на котлине.
    каждое 1е приложение, я б сказалп.
     
     
  • 3.39, Аноним (39), 05:03, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это неправда.
     
     
  • 4.52, Аноним (54), 12:06, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ладно, с большим запасом - каждое второе
     
  • 2.105, zionist (ok), 19:46, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да, но мало где. Например знаю один банк, в котором решили всё писать именно на Котлине.
     

  • 1.28, зомбированный (?), 22:35, 19/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    жаль, что Visual J# забросили - это бьыло лучшее от С# u Java...
     
     
  • 2.46, Аноним (45), 09:25, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    всё где есть j нафиг нужно
     
     
  • 3.47, зомбированный (?), 09:29, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    нельзя всех под одну гребёнку - ты говоришь, как зомбированный...
     
     
  • 4.49, Аноним (45), 09:53, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    я говорю как человек с головой на плечах
     
  • 2.51, Аноним (54), 12:04, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    J#, C# - это все потомки J++ и WFC - это был действительно качественный прорыв в то время (конец 90х), но не сильно замеченный из-за склонности M$ пытаться загонять все языки программирование в ствое стойло - Windows & COM
     
     
  • 3.95, iZEN (ok), 23:24, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И архитектор у них один — Хэйлсберг (человек, который придумал Delphi).
     
     
  • 4.108, Neon (??), 02:34, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Жаль загубили C++ Builder и основной упор был на Pascal, а не на С++
     
     
  • 5.119, Аноним (54), 20:10, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Delphi был изначально.

    Это уже потом где-то к версии Delphi 3 появился С++ Builder 1.0, но тоже на базе Delphi и VCL (при этом не совсем удобный).

    А до него был Borland C++ с OWL (аналог MFC), проигрывавший Visual C++ c MFC.

     

  • 1.40, Аноним (39), 05:05, 20/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >За исключением удаления некоторых устаревших возможностей в Java SE 24 сохранена обратная совместимость с прошлыми выпусками платформы Java - большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии.

    У меня есть обратный опыт.

     
     
  • 2.61, Аноним (61), 13:52, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У меня есть кое-какой отвратительный опыт Программа написана на Scala В одном ... большой текст свёрнут, показать
     
     
  • 3.66, Аноним (-), 15:05, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Oh, it s bad luck to be you c Т е перестала работать на системе которую выпуст... большой текст свёрнут, показать
     
     
  • 4.85, Аноним (85), 17:40, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Напоминаю В след за кораблём пошёл Единственное, что конкретно прокомментирую,... большой текст свёрнут, показать
     
     
  • 5.89, Аноним (-), 19:16, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не в оправдание скажу, что пришлось опускаться ну уровень человека который пишет... большой текст свёрнут, показать
     
     
  • 6.96, Аноним (96), 00:09, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Какие вы спесивые, называть вещи своими именами у его дворянского сиятельства - ... большой текст свёрнут, показать
     
  • 3.84, жявамэн (ok), 17:39, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    шизик таблетки забыл выпить?
     

  • 1.48, Аноним (48), 09:39, 20/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Насколько java успешнее и эффективнее плюсов для вэб (апи, микросервисы)?
     
     
  • 2.53, Аноним (54), 12:20, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Настолько же насколько Мазератти эффективнее Феррари в перевозке  бетона.
     
  • 2.67, Аноним (20), 15:10, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Намного.
    Попробуй сопровождать софт, когда бизнес задачи всё время меняются и при этом есть текучка кадров.
     
     
  • 3.69, Аноним (-), 15:25, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Намного.
    > Попробуй сопровождать софт, когда бизнес задачи всё время меняются и при этом есть текучка кадров.

    Что довольно странно.
    Например в геймдеве смена задач или вообще концепции это обычная история.
    Но как-то движки и даже софт пишут на С++.


     
     
  • 4.80, Аноним (20), 17:01, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что довольно странно.

    Ничего странного.

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

    > Например в геймдеве смена задач или вообще концепции это обычная история.
    > Но как-то движки и даже софт пишут на С++.

    Дак это и не совсем веб.

    Игры создаются на базе движков, а движки обычно и выполняют самую тяжёлую работу.

    Компании типа Unity и Epic Games по серьёзному подходят к разработке движков, и нанимают больших профессионалов.

     
  • 4.117, Jh (?), 13:32, 22/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ну да, продать игру, а потом патчи выпускать - это в порядке вещей.
     
  • 2.83, жявамэн (ok), 17:37, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    на 100 процентов.
    на крестах энторпрайзные опердени как не писали так и не пишут.
     
     
  • 3.91, Аноним (54), 20:01, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Web как на PHP и JavaScript писали так и пишут.
    В последнее время к ним немного подтянулся Go.
    О Java в вебе  ни слыхали - только в жирных ынтрырпрайзах.
     
     
  • 4.93, Аноним (20), 20:18, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вместо php щас больше предпочитают python.
     
     
  • 5.103, Аноним (54), 19:01, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Python - слишком медленный для Web. Место Python - Data Engineering, Data Science, Artificial Intelligence, где Python управляет библиотеками, написанными на С++.

    Большинство WEB-сайтов в Мире написано на PHP

     

  • 1.55, Аноним (61), 13:02, 20/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > девятая предварительная реализация API Vector, предоставляющего функции для векторных вычислений, которые выполняются с использованием векторных инструкций процессоров x86_64 и AArch64 и позволяют одновременно применить операции сразу к нескольким значениям (SIMD).

    Наверняка опять заставили скот покупать процессоры. Потому что в WASM от Mozilla "поддержка векторных инструкций" реализована так: у кого нет SSE4.2 - тот может идти куда Полонский послал.

     
     
  • 2.81, Аноним (81), 17:24, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Опять владельцев Core 2 Duo обижают.
     

  • 1.56, Аноним (61), 13:07, 20/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Удалён код для поддержки 32-разрядной платформы ОС Windows на системах x86. Объявлен устаревшим и запланирован к удалению порт Java для 32-разрядных систем x86 (будет прекращена поддержка Linux на 32-разрядных системах x86).

    Это называется вредительством.

     
     
  • 2.58, Аноним (61), 13:38, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Откровенно заявляются вредительские цели иными словами - жалкие оправдания Ст... большой текст свёрнут, показать
     
     
  • 3.60, Аноним (39), 13:51, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тебе кто-то обязан, что ли, что-то, Аноним?

    Нужно, сделай сам. Или сделай компанию, которая будет предоставлять такую услугу.

     
     
  • 4.62, Аноним (61), 13:53, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я и без тебя знаю, что рыночек порешал.
     
     
  • 5.63, Аноним (54), 14:03, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сколько ты заплатил за разработку Java, чтобы писать такое? Не нравится, можешь оставаться на версиях Java, которые поддерживают твое железо - делов то. Еще куча проектов крутится даже на Java 8.
     
  • 2.65, Аноним (-), 14:38, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Удалён код для поддержки 32-разрядной платформы ОС Windows на системах x86
    > Это называется вредительством.

    Это называется уборкой.
    Когда ты протухшие продукты выбрасываешь из холодильника.

    Потому что лишний код это не только увеличение времени сборки.
    Но и
    - поддержка совместимости нового кода и старого
    - поддержка полного цикла тестирования: регрессионные и прочие тесты
    - автотесты (я надеюсь у них CI пробегает на всех платформах) будут выпонлятся дольше
    - необходимость принимать баг репорты от всяких некролюбов, и иметь проблемы с их проверками (где сейчас найдешь тестовое окружение под EOL системы?)

    В общем абсолютно правильное решение.
    Те кому уж очень сильно надо - пусть форкают и сами поддерживают.
    Все таки OpenJDK таки да Open)


     
     
  • 3.78, Аноним (85), 16:47, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Это называется уборкой.

    Когда киллер заказ выполняет - он тоже убирает.

     
  • 3.79, Аноним (85), 16:50, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Когда ты протухшие продукты выбрасываешь из холодильника.

    Пойди выброси свой протухший продукт из коробки.

     

  • 1.57, Аноним (61), 13:10, 20/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Unfortunately, any interaction at all between Java code and native code is risky because it can compromise the integrity of applications and of the Java Platform itself

    Срочно нужно готовиться к адаптации платформы под TEE. Любое исполнение неаттестованного кода - это потенциальный обход DRM!

     
  • 1.82, жявамэн (ok), 17:36, 20/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    пишем на 17
    про новые версии читаем только релизноты.

    пока не завезут стебл страктед канкаренси даже и думать нет смысла о виртуал тредах.

     
     
  • 2.87, Аноним (29), 18:09, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Пока что лучшая версия была - SUN Java 6 HotSpot Server; из-за динамической оптимизации показывала производительность даже выше, чем просто нативный код.
     
     
  • 3.92, Аноним (54), 20:04, 20/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, Гомер, быстрее скорости света... мифы - они такие
     
     
  • 4.97, Аноним (29), 00:48, 21/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Спроси у Интела, почему они стараются всякие оптимизации затолкать в проц в рантайм, а не в компилятор статически.
     

  • 1.100, Аноним (100), 17:40, 21/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Удалён код для поддержки 32-разрядной платформы ОС Windows на системах x86. Объявлен устаревшим и запланирован к удалению порт Java для 32-разрядных систем x86 (будет прекращена поддержка Linux на 32-разрядных системах x86).

    И эти туда же, казалось бы им то какой смысл - на 32 битах много чего жабного крутится - но нет, и эти доползли до ножниц...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру