После шести месяцев разработки компания Oracle опубликовала платформу Java SE 25 (Java Platform, Standard Edition 24), в качестве эталонной реализации которой используется открытый проект OpenJDK. За исключением удаления некоторых устаревших возможностей в Java SE 25 сохранена обратная совместимость с прошлыми выпусками платформы Java - большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 25 (JDK, JRE и Server JRE) подготовлены для Linux (x86_64, AArch64), Windows (x86_64) и macOS (x86_64, AArch64). Разработанная в рамках проекта OpenJDK эталонная реализация Java SE 25 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63895
Асинхроньщину уже завезли?
Виртуальные потоки позволяют писать производительный код синхронно, зачем усложнять код асинхронщиной.
2014 год, Java 8:
----
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
// Asynchronous task
return "Hello";
});
future.thenApply(s -> s + " World").thenAccept(System.out::println);2023 год, Java 21:
----
Thread.ofVirtual().start(() -> {
// Asynchronous task running on a virtual thread
});
CompletableFuture в сложных конструкциях настолько страшный получается, что им не хочется пользоваться ))
Подскажите, Project Panama уже принят в какой-либо релиз, или заброшен? Понять не могу...
JEP 454: Foreign Function зарелизился в JDK 22 - https://openjdk.org/jeps/454Vector API все еще ждет в инкубаторе, кажись они хотят его выкатить вместе с value классами.
Спасибо за ответ!
Здорово, что попало в LTS, не терпится попробовать)
> использования профилей выполнения методов, полученных при прошлом запуске приложенияТ.е. при негомогенном использовании методов (когда у нас не "один сценарий использования на однородных данных на все запуски") есть возможность еще сильнее просадить качество оптимизаций?
> тестовая реализация API Vector, [...] API даёт возможность явно управлять векторизацией для параллельной обработки данных
А вот это годно
> Планировщик Shenandoah нацелен на сокращение времени остановок во время сборки мусора
Жаль, что без остановок оно вообще не умеет и уметь будет еще ой как не скоро.
> указание в конструкторах выражений перед вызовом super(...),
Даже стало интересно, в каких ситуациях прямо так необходимо выполнять что-то перед вызовом стека конструкторов предков
> Удалён код и сборочные сценарии для поддержки 32-разрядных систем x86
Вот оно, это ваше запланированное устаревание, а не все эти роухаммеры в шапочках из фольги. Для эмбеддеда придётся вкусные фишки получать из сторонних сборок, типа российского.
> Добавлен экспериментальный API StableValue [...] разделяет создание постоянных значений и их инициализацию, гарантирует, что значение может быть инициализировано только один раз, [...] позволяет применять в пользовательском коде оптимизации сворачивания констант
А что, до этого раньше догадаться было никак?
> А вот это годноНет, это признание провала обещаний про "вы пишете высокоуровневый код, а оптимизатор сам всё сделает". Что дальше - ручное управление памятью?
На жаве пишут не те, кому нужно вручную смид юзать а те, кто не хочет про такие вещи вообще думать, типа питонистов и жаваскриптистов.
Ну, дать возможность переопределить и руками доопределить то, что javac там тебе наавтовекторизовал - на самом деле идея нормальная.
> Что дальше - ручное управление памятью?Ну, pinned objects уже были, ЕМНИП в автоматическом режиме и они позволяли напрямую, без таблицы получать и маршаллить данные в нативном коде, но тогда сходил с ума гц. Дать программисту руками закрепить в куче объект и получить на него прямой указатель было бы на самом деле неплохо.
А описанные тобой персонажи даже не всегда смогут внятно расшифровать саму аббревиатуру, пока промт чатугопоте не вобьют.
Да ну. Те, кому нужна производительность сделают на расте. Там не только всё уже есть, но и язык лучше, и прости господи эффективность по ресурсам которая у жавы всю жизнь была и есть на дне.
> Там не только всё уже есть, но и язык лучшеДальше можно не читать.
Главный прикол, что если чуть-чуть попало в своп, тебе конец буквально. Рекомендую трюк с mlockall -- очень экономит нервы. Только, нативный код может свопиться, и когда половина памяти процесса может спокойно лежать в свопе, и другая половина умирает от этого, получается не очень удобно.
> Вот оно, это ваше запланированное устаревание, а не все эти роухаммеры в шапочках из фольги. Для эмбеддеда придётся вкусные фишки получать из сторонних сборок, типа российского.Эмбеддед на 32-битном x86? Там, наверное, до сих пор на шестой яве сидят.
Ну почему?
Относительно свежие железки, на специально собранном ядре 6.14+, со свежими jvm от вендора не так давно щупал. Но проц там х86, тупо из-за стоимости партии, дешевле оказалось, чем ставить мипс или арм
Но 32 бита?
И повторюсь — Java 25 придёт туда… лет через 25.
> из сторонних сборок, типа российскогонапомните, кто у нас занимается российскими сборками?
Либерику, просьба не упоминать, они заблокировали скачивание с российских адресов.
Axiom JDK как минимум
похоже - и как "максимум", тоже.
https://lab50.net/gosjava/
>они заблокировали скачивание с российских адресов- что-то я пропустил этот момент: BellSoft перешёл на тёмную сторону?
> Даже стало интересно, в каких ситуациях прямо так необходимо выполнять что-то перед вызовом стека конструкторов предковКогда нужно передать аргумент в констриктор предка, но перед этим его нужно провалидировать или сделать какую-нибудь трансформацию. В общем фича иногда позволит отказаться от методов-фабрик.
Я понял, что мне напоминает современная жава. C++. Продолжают городить какие-то надстройки, а язык остаётся кривым и косым. Надо было не надстройки городить, а язык с нуля перепредумывать когда 9-ую выпускали. Или ваще её похоронить и сказать юзайте котлин.
> юзайте котлинВендорлок, который фиг нормально установишь без их ide.
Мне кажется Котлин сдохнет в ближайшей перспективе. Уже тысячи были более лучше жабы на JVM и где они все?
Ну пока его спонсирует гугл на своем анроиде точно не сдохнет.
В свежих AndroidStudio уже и нет возможности создавать новый Java проект. Только Kotlin оставили.
Ну, гугол свой андроид потихоньку окукливает до уровня иось, и судя по новостям, скоро запретит ставить пакеты не из своей копилки.
Самый дурацкий язык эвер. Например, в нем нельзя объявить переменную с типом "строка". Нет, String -- это "строка ИЛИ нулл". А вот "просто строка" -- нельзя. Так что везде, где ты работаешь со String, тебе приходится держать в голове, что он может быть нуллом. В нормальных языках такого нет. Даже в тайпскрипте string -- это реально только строка, без всяких неявных null | undefined. А еще в яве нет top type и bottom type. Нет, Object -- не top type, потому что он не покрывает примитивы. Нет, boxed types -- не примитивы. В общем, систему типов в яве уже не спасти.
Слишком толсто, попробуй потоньше.
Попробуй объявить в яве переменную с типом "строка" -- такую, чтобы компилятор не давал присвоить ей нулл. А теперь послушаем твое отсутствие ответа и всяческие виляния:
Главный вопрос - зачем? Твой код принципиально не умеет в нуль? Лови NPE!
Функция, которая делает что-то со строкой, не должна проверять, что ей передали один из двух вариантов. Иначе в рантайме приложение только и будет заниматься тем, что проверять переменные. В норм языках рантайм-проверки переносятся в компайл-тайм.Задумайся сам над бредовостью: "я -- функция, которая вычисляет количество гласных букв в строке. Я принимаю либо строку, либо нулл! Если передали нулл, я... кхе-кхе... читай документацию в общем. На уровне ЯП я не могу тебе сообщить, что будет, если мне передадут нулл. Смотри явадоки!" В итоге контракт функции определен слабо. Может упадет, может нет. Надо лезть в реализацию и смотреть, как обрабатывается нулл. Либо читать явадоки, если они актуальные.
В норм языках: "я -- функция, которая вычисляет кол-во гласных букв в строке. Я принимаю строку". Все просто и понятно. Но именно в яве такое не выразить.
А ты не передавай нуль в функцию, которая ожидает строку, иначе ява за тебя любезно кинет ошибку.
Вот именно, что ява кинет ошибку лишь в рантайме. А должна была в компайл-тайме. Допустим, эта строка у тебя член класса. В какой-то момент, спустя полгода-год, когда ты уже напрочь позабыл о кодовой базе, тебе прилетела задача: член класса иногда должен хранить нулл. Ты внес правки, запустил -- вроде все работает (функция еще не вызвана). И тут, после выкатывания на прод, функция наконец-то запустилась, например по таймеру раз в неделю, и получила нулл. Будь компайл-тайм проверка, ты бы о проблеме узнал задолго до. Вывод: ЯП должен следить за ненуллабельностью на всех уровнях. Отсекать не только getVowelCount(null), но следить, что при getVowelCount(this.someString) этот самый this.someString никогда не бывает нуллом. Или что getVowelCount(this.someString) всегда оборачивается в if (this.someString != null). В норм языках такие проверки есть. В яве -- нет.
Ну так добавь линтер в CI, делов-то. В яве есть @Nullabe и @NotNull если чо.
Линтер-шминтер. Это задача языка следить за типами, а не стороннего линтера, который можно и отключить.
а ты не отключай!
Тебе шашечки или ехать? Если первое, то этот язык с богатейшей историей, библиотеками на все случаи жизни (включая довольно обскурные протоколы), литературой, и, главное, опытом разработки больших коммерческих систем тебе совершенно не подойдёт. Ищи в другом месте. Если второе, то за время которое ты потратил на нытьё в опеннете можно было включить в CI/CD линтер, поправить ошибки и занять чем-то более продуктивным.
> Вот именно, что ява кинет ошибку лишь в рантайме. А должна была
> в компайл-тайме.Компилятор должен это проверять. При каждом обращение к строке? Вы просто не правильно поняли что такое строка в java. Я использую одну и ту же строку при переводе на 100 языков. Должен ли компилятор каждый проверять валидность строки? Функция вернула строку в качестве результата. Должен компилятор генерировать код проверки и где? Внутри вызванной функции или снаружи?
> Компилятор должен это проверять.Смотри, объясняю для особо одаренных: проверить на этапе компайла означает, что проверка происходит ровно один раз, во время компиляции, на машине разработчика, компилирующего софт. На проде проверок нет вообще. Отсутствуют. Absent. Non-existent. Код в рантайме такой сразу без проверок: "это строка и точка, я верю, что там строка, не буду тратить такты на проверку". Вот что такое "компайл-тайм-проверка". В яве они отсутствуют напрочь, приходится в рантайме проверять либо вручную (явным ифом), либо как-то генерить ифы, но факт остается фактом: это уже "рантайм-проверка". Потому что код в рантайме такой: "ага, может быть нуллом, надо потратить такт и проверить". Итого, по-настоящему безопасные ява-проги безбожно тормозят. А по-настоящему безопасные НЕ-ява-программы с sum types -- летают.
btw неа, не будет там лишних тактов на проверку на null. C2 повешает инвариант и поймает хардварным исключением если что-то что не должно быть null'ом им окажется. Он даже может выкинуть ручные проверки на null и, реконструировав стекфреймы, притвориться что они таки таи были и сработали, но сработали в реальности не они, а pagefault у цп. Да, его можно выбесить если таки часто засовывать null'ы в такую функцию, он выкинет инвариант и натыкает классических ифов, но тогда вы уже ссзб. И кардинально переделать систему типов уже никак не выйдет, не сломав вообще весь уже написанный java код, а его ой как дохрена и никто на такой самоубийственный шаг не пойдет.
> кардинально переделать систему типов уже никак не выйдетПотому я и написал, что яву уже ничто не спасет.
Вы рассчитываете на "идеальную машину выполнения", где есть только ваша программа и бесконечная память. По факту, за Вас компилятор обращается к ОС, которая крутит множество потоков в ограниченной памяти, через системные вызовы, которые Вы в другом комментарии записали в "инструмент бога" (цитата - "ты хоть знаешь, что это такое?" - знаю и знаю что возможен отказ в предоставление ресурсов и надо анализировать возврат и что это требует больших затрат тех самых тактов, которые Вы считаете, потому что используется инструкция pusha/popa (затолкнуть/извлечь все общие регистры в стэк) два раза - до и после сискола)
Можно долго стекаться по древу знаний, но резюмируя скажу, что нормальными языки кажутся на огромном ресурсе. Вы как программист, извините, абстрактный. На системном уровне не программировали, скорее всего, если не знаете что в рантайме случается всякое.
Пока есть такие как вы, я спокоен за своё рабочее место. Пожалуйста, ничему не учитесь и оставайтесь собой, на вашем фоне мы выглядим богами и получаем кучу денег.
Не понимаю Вас. String это класс, а не ячейки памяти. У класса есть методы, работы с данными типа String и их нельзя "натравить на адрес памяти". Null это отсутствие объекта. Кроме того объект может в любой момент быть перемещен в памяти при изменение - это новый объект. Это основы объектного программирования. Хорошая практика проверять ссылку на наличие объекта.
> Хорошая практика проверять ссылку на наличие объектаХорошая практика -- перенести такие проверки в компайл-тайм. Если твоя парадигма такое не позволяет, то получаем тормозной софт, где все проверяется в рантайме. Впрочем, явистов тормозами не напугать, уже привымкши.
Смешно, то ли дело котлин с a?.b?.c?.d? и так несколько раз, когда надо-то было только a проверить единожды.
>Хорошая практика -- перенести такие проверки в компайл-тайм.Это как? А если объект "динамический". Запросил ты у ОС память под буфер, как компилятор узнает и проверит это (если ты не написал исключение, и нет "общеругательного" исключения или просто ОС снимает приложение за оговоренные исключения). Приложение решило открыть файл - кто сказал что он существует. откуда компилятор это должен знать и под какую ОС писать выворачивание их этой ситуации компилятору?
В лучшем случае будет test rax,rax (проверка на ноль) je preexit. если компилятору объяснить что это адрес.
> Это как?Ну ты серьезно сейчас? Совсем не выбираешься из ява-мирка?
> Запросил ты у ОС память под буфер, как компилятор узнает и проверит это (...).
Перечитай вопрос что ли. "Как компилятор узнает и проверит"... что? Что именно здесь компилятор должен проверить?
> Приложение решило открыть файл - кто сказал что он существует. откуда компилятор это должен знать и под какую ОС писать выворачивание их этой ситуации компилятору?
Ты щас про яву или что? Потому что в яве будет стрельнуто исключение. А я говорю не про IO или сисколы (знаешь хоть что это такое?), а про обычную ситуацию: у тебя в стеке (который не надо malloc-ить!) лежит строка, но по канонам явы там лежит "либо строка, либо нулл". Ты сам положил туда строку, но максимум, что ява может тебе сказать, -- это то, что там "либо строка, либо нулл". Повторяю: в норм языках (которые ты явно не изучал) такое обрабатывается легко и просто. В яве -- нет. В яве чрезвычайно устаревшая парадигма из 90-ых. Хотя чёй-то я, sum types придумали задолго до. Но ява оказалась устаревшей еще в самом начале, прямо в момент своего появления.
> Перечитай вопрос что ли. "Как компилятор узнает и проверит"... что? Что именно
> здесь компилятор должен проверить?Так это Вы утверждали, что проверить исключение рантайм должен по-хорошему компилятор, во время компиляции. Вы хитро перевернули тезис.
> А я говорю не про IO или сисколы (знаешь хоть
> что это такое?), а про обычную ситуацию: у тебя в стеке
> (который не надо malloc-ить!)Вы создали объект класса стэк. Я думаю вы не имеете в виду стэк вызова функции, куда пихаются параметры когда их много. Вы не проверяете, удалось ли создать этот объект? Прямо в уверенности существования и используете? Тут неявно используется динамическое выделение памяти.
> лежит "либо строка, либо нулл".
Если Вы передали этот объект класса стэк в другую обработку, которая извлекает из стэка и помещает в стэк, то ручаться, что в стэк не затолкнули висячую ссылку нельзя. Если Вы сами поместили и тут же извлекли, то можно ручатся за сохранность, если ваш поток, единственный использующий этот стэк.
> Повторяю: в норм языках (которые ты явно
> не изучал) такое обрабатывается легко и просто.Если не секрет, какие это языки. И априори утверждаете, что я их не изучал?
> Так это Вы утверждали, что проверить исключение рантайм должен по-хорошему компилятор, во время компиляции.Так очевидно же, что имелись в виду не IO, а ситуации, где гарантированно нет ошибок.
> Вы не проверяете, удалось ли создать этот объект?
Если памяти нет, ява тупо упадет. Но если строку создать удалось (удалось, Карл! вот она! создалась!), то ДАЖЕ после этого ява тебе будет продолжать говорить, что "либо строка, либо нулл". Чуешь разницу? Нету в яве такого, что "если памяти нет, то new Person() вернет null". Если памяти нет, ява усё.
> Если не секрет, какие это языки
Любые со строгой типизацией и sum types.
Вот и выросло поколение вкатунов, не знающих устройство ЭВМ. Все не примитивные типы в яве - это указатели на память. Когда передаёшь string куда-то - то передаётся только указатель, сама строка никуда не копируется при этом.
Где я сказал, что объект типа строка передается по значению?
Где я сказал что строка передается не как адрес? Вот только то что рядом с этим адресом должно иметь, ожидаемую методом или функцией, структуру.
Только не указатель, а ссылка. Это известно. Объект - структура по определенному адресу с полями и vtable. Ссылка передается неявно методу, который знает как работать с этой структурой (чаще через регистр RCX/ECX). Потом метод использует RCX для передаче ссылки другому методу, который вызывает. Код метода разных объекта одного класса не дублируется. Я оправдался перед вами?
> String -- это "строка ИЛИ нулл"Зумерки потихоньку начинают осозновать как работает ПК.
Обработать нуль могут не только лишь все. Мало кто может это делать.
Бумерки потихоньку продолжают не осознавать разницу между ЯП и машинным кодом. С их точки зрения, все, что возможно в машинном коде, должно быть возможно и в ЯП. Результат немного предсказуем: тысячи и тысячи CVE в софте на одном известном языке. И это лишь за один год!
Благодаря этому у тебя есть ОС и какое-то ПО которое умеет больше чем перекладывать джсоны. Удачи написать ОС на питоне или Яве, со всеми драйверами, видео и прочими требующими нормальной оптимизации вещами.
спешу тебя огорчить:
JavaOS — микроядерная операционная система на базе Java, разработанная как фреймворк для кнопочных телефонов и первых смартфонов. В отличие от большинства практических операционных систем, которые написаны на Си, JavaOS полностью написана на Java: от ядра до графической и оконной системы, реализующей AWT API.
> спешуПоспешишь - людей насмешишь. "Первый выпуск 1996. В 1999 году Sun и IBM объявили о закрытии проекта." Ой, что-то пошло не так?)
от этого оно что, перестало быть операционной системой?
трудно назвать это ОС, если нет консолей и сетевого стэка.
Особенно если придумать своё собственное определение термину «Операционная Система». Можно ещё придумать свой собственный язык и разговаривать только на нём. Но не надо удивляться, когда вызовут санитаров.
Phantom OS пободрее.
>JavaOS полностью написана на Java: от ядра доСогласно законам физики ядро и иные системные части пишутся на ассемблере и Си. Код Жабы выполняется на виртуальной машине.
Что и требовалось доказать.
У JVM нет доступа к регистрам CPU, не говоря уже об адресах памяти. Все такие прожекты без исключения - ядро на C с ассемблером, и JVM поверх него.
Со стороны это выглядело так: люди поработайте на мой патент.
А почему разговор только про строки? Это нулсейфти которого пока нет в java, в новых языках ифномрацию о нулабилити добавляют прямо в тип, таки да, это удобно. В java обещают когда-нибудь сделать с сохранением миграционной совместимости. Но пока во всех языках коим более 25 лет такого нет.
В жабе вообще много чего нет, нет перезагрузки операторов, нет каррирования, недавно не было деструктурнига, теперь какой-то есть у record классов, но синтаксически выглядит так себе.
Вообще если языка сильно переделать то это уже будет не java, кому нужен современный язык на JVM выбирают Kotlin. Тем более сейчас jetbrains допиливает lsp server и тогда можно будет с их языком работать практически из любой ide.
Кстати, еще не хватает дефолтных значений аргументов методов, и сопоставление аргументов по имени. Brian Goetz пообещал что этого никогда не будет в java :)
А вот по поводу перегрузки типов он пообещал в будущем сделать что-то, он думает ввести алгебраические типы позаимствовав идеи из функциональных языков. Но это уже будет после value class, одно за другое цепляется.
Идет в ногу с трэндом. Всем надоели индивидуальные кнопочки и разные рюшечки. Требуются молотилку цифр. Только это не площадка jvm. Для "удивить java программистов скачком производительности" пойдет.
Это обещают с value class, пока они в preview. Value class + vector api и жаба магическим способом превращается в числодробилку. Но это пока в теории.
Эпопея с нуллами в строках крутится вокруг ровно одного факта — в БД (и сиквеле) нуллы в строках есть. Всё.
Лучшее, что можно попытаться сделать — кастовать их к String.Empty или около того. Как оно по производительности будет — не знаю, но противники будут.
Полностью от нуллов нельзя избавиться (как и от undefined в динамических языках).
"даже в тайпскрипте". Ну ты и сказанул. Тайпскрипт это весьма хорошо спроектированный язык, с учётом того, что компилируется в жс, даром что Андерс Хейлсберг создавал.
>компилируется в жсКаждый раз, как в первый
>в нем нельзя объявить переменную с типом "строка"Да, в Java нет встроенного типа "строка". (Как и в C и C++). Ну и что? Есть же объект String
StableValue is nonsense
Это же что то должно охранять.
Скажите, а пришедший ещё в Java 9 JPMS (модульность) кто нибудь реально использует в своих проектах? А без Ломбока и Спринг Бута кто-то ещё на Джаве программирует?
Эта модульность нафиг была не нужна.
> Эта модульность нафиг была не нужна.На самом деле была нужна, но с версионированием - для разрешения конфликтов в транзитивных зависимостях. В версионирование они не смогли, хотя этот долгострой делали около десяти лет! В итоговом виде оно действительно никому нафиг не нужно. Я уже год как ушёл с Java на Go и тут конфликты версий решаются удивительно просто.
Да и да
Я ещё ни разу не видел, что бы кто-то эти модули юзал. Прогаю на жаве с версии 1.4.
Мы используем при написании библиотек и если на проекте гексагональная архитектура, чтобы явно лишить возможности тянуть код адаптеров в модуль доменной логики.
Самый лучший язычок для линукса! Многие GNU фа натики критикуют джаву за ресурсопотребление - так вот, безопасный язык лучше вечной CVE сишки. Таким образом, джава - это зрелость и солидность, а сишка - язычок из 70-х годов с UB.
Жаба не тормозит - вот и Томми в курсе.
Это какой Томми? Из Большого куша?
> Это какой Томми? Из Большого куша?Который робот из DARPA Grand Challenge
Понятно. Томми из "Большого Куша" поверил бы, что java не тормозит.
Сейчас спросил у DeepAI. Он не упомянул JAVA в контексте Томми из DARPA Grand Challenge. Поясните, если не сложно.
Да гуглится все. Лет 20 назад было соревнование машин на автопилотах, и Томми, под управлением Linux и программы на Java, врезался в стену на скорости 100 км/ч.
DeepAI сказал другое. Томми - автономный автомобиль от команды Stanford Racing был участником и победителем. Вот ссылка - https://en.wikipedia.org/wiki/DARPA_Grand_Challenge
На вопрос: "Какое ПО использовал Томми?" DeepAI не упомянул java, а вики говорит, что команда использовала свой исходный код. Непонятка и вызвала просьбу.
"Жаба не тормозит" можно отнести к характеристики натуры человека или самой java (на предмет потребления памяти)
Ну, если ты инвалид, и без UB писать на C не можешь, кто тебе виноват?
Парниша, ты не в курсе, что даже такие мастера сишки как Теодор Тцо делают UB в своём коде. А? Безопасный сишный код без UB - миф, это всемирно известный факт.
C# давно выбил это место у джавы
Только лишь на винде, но не на линуксе и мак.
10 лет назад писал код на Жабе. При компиляции всё время не компилировался показывал какую-то ошибку. Как только код завернул в блок исключения. Так код сразу скомпилировался.Такая куита ещё осталась. Вы всё время свой код оборачиваете в блок исключений. Ваш код на 10% состоит из исключений.
> какую-тоВ этот и состоит Ваша проблема. Не языка, а Ваша.
Если усложнять ради усложнения, то получится Си.
Си как раз максимально упрощен.
Он перепутал C++ с чистым Си.
Но недостаточно, до уровня Brainfuck ещё не упрощён, недоработка.
Вот ножовка — казалось бы, проще не придумаешь. Но сцуко электропилой работать гораздо удобнее.
Ну и чем вам исключения не угодили?
Ему они неинтересны, это проблема пользователя.
В джаве известные проблемы с неправильно спроектированнымми исключениями.
> В джаве известные проблемы с неправильно спроектированнымми исключениями.И это повод не пользоваться исключениями? Я просто мысль до конца не понял. Так-то и в процессорах ошибки встречаются, но ими же пользуются, а не считают на счетах-)
скилбоксовский?
Нет рабочий.
>При компиляции всё время не компилировался показывал какую-то ошибку.Это фича Джавы - обязательная обработка всех возможных исключений.
> обязательная обработка всех возможных исключенийне всех, а только checked. Есть и unchecked (RuntimeException и производные).
Хорош ли Java, как язык программирования? Лучше ли, чем Python?
Сама по себе Java хороша. И она реально быстрая.
Другой вопрос что она потонула в корпоративном овнище где пишут "для резюме" обклаываясь интерфейсами, проксями, паттернами ради паттернов а не реальной необходимости.
И когда jmv приходится продираться сквозь сотни прослоек виртуальных интерфейсов (их реально сотни, достаточно глянуть стек-трейс в реальных приложениях) все вложенные усилия в оптимизацию идут лесом.
> Сама по себе Java хороша. И она реально быстрая.Сама по себе быстрая, да. А вот реализации её виртуальной машины медленные и жручие.
Ява обладает высокой производительностью. Под "высокой" мы понимаем достаточную. Под "достаточной" - низкую.
По сравнению с пыхом или руби с пистоном - джава супер производительный язычок!
Да совершенно на одном уровне они. Вопрос не в производительности, у жавы всегда тонны дохлого легаси с уязвимостями.
Пишу на флаттере. Легаси мало, но через пару лет программа перестает собираться: старые библиотеки не работают в новом sdk. Новые библиотеки в старом sdk.
А ты будь моднее.
В английском на этот случай есть слово pretty в функции наречия - достаточно, приемлемо.
Java is Pretty quick.
Степень быстроты не обсуждается, а каждый подразумевает свою.
> Сама по себе быстрая, да. А вот реализации её виртуальной машины медленные и жручие.Смотрю как код на яве обрабатывает ~400 qps на трёхстах мегах рам и не вижу тормозов. Упирается в I/O сетевых интерфейсов, и хоть ты тресни. Как так?
> Сама по себе Java хороша. И она реально быстрая.Так обычно рассуждают те, кто быстрее ничего в жизни не видел. Ну как мне коллега сегодня сказал, что с новым редизайном микросервиса, который клюя значение в базу кладёт теперь сможет даже что раз в секунду это делать. Я с вас, жаверов, просто х-ю порой.
Твой коллега криворукий просто. Джавка жирная и любит кушать heap, но у нее за 30 лет JIT компилятор научился оптимизировать генерируемый машинный код не хуже чем gcc/clang делают это для С++. Есть проблемы с числодробильными задачами, завязанными на CPU, но джавка всегда была преимущественно языком бэкенда, где основные причины тормозов - это сетевое IO. А скорости эффективно JSON нарезать и лазить в БД у нее за глаза, особенно когда сервис поработает в проде пару часов и основная бизнес-логика откомпилируется JIT-ом и закэшируется в виде готовых blob-ов в машинных кодах.
Что лучше? Арбуз или колбаса?
Меня, как человека, который только чуть-чуть потрогал Java, с души воротит с языка, в котором встречаются типы
- const static
- static final
- const static final
Не понимаю, зачем такое городить?! Но я не программист, может тут и правда есть какой-то сакральный смысл.
Ты и правда не программист. В жаве нет const.
Скажу общё - если вы имеете дело с абстракцией, то всегда надо уточнять с какой конкретно.
А так, отсылаю к документации.
> В жаве нет const.Нет есть. Ключевое слово const зарезервировано, но ничего не означает.
Язык - уг. Котлин лучше, раст лучше. Сишарп говорят хороший, но это по слухам.
Ждём, когда будет предложен компактный вариант оформления программ, в котором не требуется определение лишних классов и методов, автоматически импортируются типовые API и доступны упрощённые методы ввода/вывода. Например, приложение "Hello, World!" можно будет свести кIO.println("Hello, World!");
echo "Hello world"bash смотрит на тебя с недоумением.
Как это куда-нибудь поместить. Ваши строки не Вселенная.
Оберон что ли?
jshell> System.out.println("Hello, World!");
Чет я не понял, а кто жаву у Ларри счас готовит, он-же вроде всех проггеров, кто не с базой, прогнал. Или я че-то путаю?
Вроде как Ларри сам уже ушёл из Оракла
Да, ну?! Вот это поворот. А кто-ж теперь вместо него, Илон?
Илона он уже обогнал:
"В сентябре 2025 г Ларри Эллисон впервые стал самым богатым человеком в мире, положив конец почти годичному правлению Илона Маска на первом месте"
Унылейшие язык и рантайм, извечно отстающий на десятилетие даже от достаточно консервативного сишарпа. Сколько лет понадобилось, чтобы генерики не паковались в object? Это же шиза.
Не умер только благодаря ведроиду, но с одной стороны всех переводят в /*котёл*/ котлин, а с другой азиаты по чуть-чуть уходят в хуавеевский кандзи.
> Сколько лет понадобилось, чтобы генерики не паковались в object?Воз и ныне там. Дженерики в джаве невозможно переделать ввиду ограничений jvm.
В 202к5 коду брать джаву не имеет смысла, дотнет открытый и в целом лучше
Да и дотнет не имеет смысла брать тоже. Это всё легаси языки.
>дотнет открытый и в целом лучшеА приятно ломается... )
Гугли Project Valhalla, где собираются релизнуть value классы и специализацию дженериков примитивами.
Долгострой ппц, но когда релизнут, все джависты побегут открывать шампанское, так как в языке снизится до минимума pointer chasing, фрагментация кучи и количество cache miss.
> Гугли Project Valhalla, где собираются релизнуть value классы и специализацию дженериков
> примитивами.Да как бы поздно уже. Все, кто хотел производительности пересели либо на c++/GO/rust, либо на c# как наиболее совместимую альтернативу
Ну, если говорить про РФ, то с банков (а это главный российский кровавый ынтерпрайз) его поперли, когда у Java JDK начали появляться отечественные сборки OpenJDK, сертифицированные ФСТЭК-ом (Liberica/Axiom). Я лет 5 только тем и зарабатывал, что на галере давали очередной проект, где C# легаси нужно было переписать на джаву.
Насчет "производительности" - джава всегда была нужна преимущественно на бэке, где основное бутылочное горлышко - это сетевое IO, а не CPU-bound задачи. Если руки прямые и есть понимание как тюнить GC под профиль нагрузки (микро)сервис, то сервис, держащий 50K RPS в один инстанс - не проблема.
А так конечно C# будет по-прогрессивнее - язык вышел в нулевых как работа над наиболее одиозными моментами жабы, которые не пофиксят никогда из-за святой "обратной совместимости".
>то сервис, держащий 50K RPS в один инстанс - не проблемаЗвучит как типовая задача для Erlang
Лучше бы поддержку 32 битов вернули. Но ломать - не строить.
> Лучше бы поддержку 32 битов вернули.Зачем? Для некрожелеза и некроjava сойдёт.
Без пары ярдов долларов я со стула не встану...
>Лучше бы поддержку 32 битов вернули- скоро не останется ОС на которых такое будет работать
А можно запилить такой же тред про последний C++