Вышла Java 21 LTS

Про «Стандартные ограничения типа «не блокировать event loop» (т.е. carrier thread) в силе. Т.е. только IO задачи.» там ничего не написано, ну или я не нашёл.

В любом случае это всё не проблемы. Просто задай нужное число нативных тредов и всё.

В Java идеальная обратная совместимость. А ты походу хочешь, чтобы люди писали код на Java 17, а ты запускал его на Java 1.2 под windows 95. Такого нигде нет.

Про «Стандартные ограничения типа «не блокировать event loop» (т.е. carrier thread) в силе. Т.е. только IO задачи.» там ничего не написано, ну или я не нашёл.

Возможно это (то что основной юзкейс - IO-bound задачи) не декларируется, потому что подразумевается.

Так или иначе в обсуждениях на всяких реддитах, почтовых листах итд, а также презентациях это упоминают.

В частности:

https://youtu.be/UjzLaVI87mA?si=Eweo3n3umBT8s7Mm&t=1208

https://youtu.be/WsCJYQDPrrE?si=EM1UYDz8z5plJ04r&t=668

По совокупности это все равно специализированный инструмент, ограничения которого надо понимать, т.е. не просто «легковесные потоки почти без изменений в коде»

Обратная совместимость (для платформы) это когда старый код работает на новых версиях платформы. Тут вроде бы все ок.

К слову, MS недавно проводили эксперимент по впиливанию зеленых потоков в .net на замену async/await, и столкнулись в общем-то с теми же проблемами. У них ситуация сложнее - .net исторически по характеру приложений, которые на нем делают, с нативом взаимодействует чаще.

https://github.com/dotnet/runtimelab/issues/2398

Понимать много чего желательно. Но я через пару месяцев переведу свои приложения на следующий спринг бут и 21 жаву и весь мой старый код заработает виртуальными потоками. Он и так был блокируемый, поэтому я просто напросто получу на халяву буст производительности. Поэтому это именно что легковесные потоки без изменений в коде.

это когда старый код работает на новых версиях платформы. Тут вроде бы все ок.

ну не скриншотами-же тут посверкивать..вчерашнее: FreePlane не может запустится в офтопике, если в оном накатана актуальная Java. Она слишком новая. «да здравствует обратная совместимость!»

Си очень низкоуровневый. Он сейчас, конечно, оптимизируются, но раньше это был прокачанный макроассемблер.

У C++ есть:

• ООП - сильно повышает уровень абстракции
• принцип RAII, что позволяет избежать ошибок с освобождением памяти, закрытием сокета и т.п.
• шаблоны. В Си, если нужно что-то подобное, приходится насиловать препроцессор. А искать ошибки в макросах размером в 200+ строк это сомнительное удовольствие.
• Возможность кастомизировать самые низкоуровневые процессы. Например, если мы в программе выделяем миллион объектов по 10 байт на куче, то гораздо эффективнее выделить сразу 10E7 байт, а потом просто распределить их по этим объектам, чем обрабатывать миллион программных прерываний (системных вызовов). И мы можем написать свой собственный аллокатор памяти, при этом уровень абстракции ни капельки не упадёт, мы просто определим работу «низухи» по-другому и весь остальной код менять не придется вообще никак.

В результате, чтобы написать настолько оптимизированный код на Си, его нужно от начала и до конца представить в голове, а малейшее изменение потребует значительных правок.

Bitwig. Морда на жабе.

Да, Double Commander на нём написан, например.

Что за бред ты несёшь?

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

Зы. Что такое клиентский Windows? Ты вообще в курсе, как и где работает Java?

Ты вообще в курсе, как и где работает Java?

теперь в курсе - Java работает только в серверах и на машинах разработчиков :-)

Ниасилятор установки клиентской джавы.. Суксь, суксь, суксь

За. Я правильно понимаю, что весь ойти из РФ уехал в 2001..07 годах?

А еще пять звезд.

Зы. Ты бы еще на дотнет пожаловался бы. Что он тоже требует установки.

А вот в Делфи все было в одном EXE. Такую систему про..ли. Да.

ну не скриншотами-же тут посверкивать..вчерашнее: FreePlane не может запустится в офтопике, если в оном накатана актуальная Java. Она слишком новая. «да здравствует обратная совместимость!»

Это проблема фриплана, а не жавы. В жаве нет ошибки «слишком новая».

нет. только изучал возможность. есть платные решения на граале для сборки для андройда и ифона. есть ещё RoboVM для ифона. но он про джаву в целом

для андройда на андройдовом апи делаю.

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

вот) такое возможно когда спецификация стабильна. в джаве она обычно формируется во время разработки)

Ждём, когда Spring перестанет поддерживать Java 17, чтобы у множества проектов бомбануло. Как они сделали с Spring 6.x (пруф). Если кто не в теме, в Spring 5.x есть критические уязвимости, которые они отказываются чинить, а для множества open source проектов слишком болезненно переезжать на новую версию спринга и выкидывать поддержку относительно старой джавы. В итоге патовая ситуация - либо проект доступен множеству пользователей, но дырявый и любой сканнер уязвимостей высветит CVE 10.0 CRITICAL ACHTUNG, либо наоборот.

та ты шо

5.3.x is the final feature branch of the 5th generation, with long-term support provided on JDK 8, JDK 11, JDK 17 and the Java EE 8 level. (с)

We fully test and support Spring on Long-Term Support (LTS) releases of the JDK: currently JDK 8, JDK 11 and JDK 17, as well as the upcoming JDK 21.(с)

спринг сложный

Это прекрасно, но уязвимости закрывать все-таки надо: пример на гитхаб

За отнесение checked exceptions к плюсам джавы лучи ненависти. Это настолько неудачное решение, что в Lombok есть даже имеет специальную аннотацию для отключения этого самого. Но аннотации нельзя применить к лямбде и они по-преждему превращаются в монстров, если где-то попадается метод с throws. Кстати, ни один другой JVM язык не имеет checked exceptions и это жжж не спроста.

Кстати, ни один другой JVM язык не имеет checked exceptions и это жжж не спроста.

да. маркетинг называется

как жить когда ваши тесты не покрывают unchecked exceptions. приходится ковырять внутрь и выяснять что там может выбросить исключение и какое

Но аннотации нельзя применить к лямбде и они по-преждему превращаются в монстров

можно сделать функциональный обработчик и тогда лямбда будет выглядеть красиво

важно помнить что:

количество скобок не влияет на скорость работы байткода

«There is currently a lack of manpower in the Gentoo Java team.»
https://wiki.gentoo.org/wiki/Project:Java

А есть в Gentoo вообще какие-нибудь такие места, где нет «lack of manpower»?

Если Java так хороша, почему тогда на десктопах нет ни одного java-приложения?

Я пользуюсь одним десктопным Java-приложением (это игра freecol).

Ну и в 6 проблему решили, удалив HttpInvokerServiceExporter нафиг… Всё, что они смогли сделать в 5.3, не нарушая обратной совместимости, — объявили его deprecated.

Проблема не в проверяемых исключениях, как таковых. Проблема в том, что их заабузили в стандартной библиотеке. Если бы они были исключительно как инструмент для пользовательского кода, а в библиотеках было бы принято использовать непроверяемые исключения, у меня претензий бы не было. Изредка кажется удобным заставить вызывающий код обработать исключение. Очень редко, но ситуацию такую представить можно.

А что касается лямбд - проблема не выглядит нерешаемой. Просто они немного забили. Но в целом - надо просто сделать так, чтобы код вроде

@FunctionalInterface
interface Function<T, R, E>
  R apply(T arg) throws E;
}

Выводил тип E как, к примеру, IOException | SQLException. Причём код выше уже работает для одного вида эксепшнов. А также вышеупомянутая концепция типа-объединения уже есть в языке в виде соответствующей catch-конструкции. То бишь в целом в языке уже все кирпичики есть, осталось только их соединить и проблема с лямбдами будет решена.

Если Java так хороша, почему тогда на десктопах нет ни одного java-приложения? (IDE – инструмент разработки)

Так получилось что у Java нет нормального десктопного фреймворка. Была бы поддержка того же Qt на Java, то были бы и приложения. Вон на Python-е хоть отбавляй. Swing норм, но сыроват по сравнению с Qt. Кстати, с C# такая же история.

sdrtrunk, rivet, YACC, jsquelch. Вещи ну прям очень специфичные, и тем не менее не IDE, ведроид или вебня.

GIL не тормозит?

tuxguitar, jdownloader2

biwig(частично), dbeaver и sweethome3d тебе уже напихали, или опять, «это не то, покажите нормальные приложения» - ?

Spring Boot честнвй, чоткий и ровный

Весь банковский сектор крутится на Кобыле под ДОМ с зелеными мерцающими экранами.

А не на джаве

Я правильно понимаю, что уехавших из Сбера и Тинькофф айтишников заменят посетители младшей группы детского садика Орлёнок?

Вчера эксперт по Коммерсант ФМ об этом говорил. Насколько это хорошо для экономики РФ.

compilation time is so fast that you usually do not notice it

Угарнул, спасибо

tuxguitar

ок.

jdownloader2

Это и какой нибудь vuze могут использовать люди не … хотя в концов они и Discord юзают. Так что это для меня не в тему.

biwig(частично),

Это я хз что такое.

dbeaver

Я когда писал минус IDE это я имел ввиду не проги для разработки даже если они (к примеру основывались на Еклипсе). Проги для разработки это по сути не прикладная работа компа, а мне была интересна именно прикладная.

и sweethome3d

Это да, даже я как то пробовал ЭТО юзать.

Но что интересно, лично у меня почему то приложения тянущее jre вызывают какие то негативное ощущение. Недавно была какая то программа демон (для какого то банка или ЭЦП) и вроде прога нормальная и вроде пашет нормально. Но как я увидел jre сразу какое то отвращение к этому появилось, хз почему так.

тебе уже напихали, или опять, «это не то, покажите нормальные приложения» - ?

Да я не про наезд что нет приложений, просто пытался вспомнить что есть на jre и чтобы более менее использовалось аля: firefox, Gimp, LibreOffice ну и т.д.

P.S. Что касается андроида, то раньше (сейчас железка телефона сильно мощная стала) но когда вышли первые андроиды и рам там было 512-1Gb, так было обидно за андроид, так как если бы не жава там все там просто бы летало и батарею в разы меньше бы жрало. Они что нормальных программеров на си не нашли что ли …

Уважаемые джависты, можете, пожалуйста, накидать линков на примеры (кода) использования Hibernate в нескольких инстансах приложений, запущенных на разных узлах, но чтобы у них у всех был один и тот же shared Hibernate L2 Cache, расположенный, например, в Redis или Tarantool кластере?

Т.е. чтобы кэширующий кластер не дублировал данные для каждого отдельного процесса, использующего Hibernate, а чтобы был один общий кластерный L2 Cache сразу для всех процессов, такое ведь возможно?

Да я не про наезд что нет приложений, просто пытался вспомнить что есть на jre и чтобы более менее использовалось аля: firefox, Gimp, LibreOffice ну и т.д.

IBM Notes был когда-то:)

Ну так это была по сути групповая работа и юзали мы ее под OS/2.

к чему это?

Ну вы напомнили мне про Notes, а я тут же вспомнил когда это юзал …

Кстати, с C# такая же история.

Для C# есть хотя бы Avalonia UI, не говоря уж о WinForms и WPF для Windows/WINE.

Генерики - это хорошо. Try-with-resources - это хорошо. Остальное - лишнее, просто лишнее.

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

Согласен. Если бы проверяемые исключения были только в коде бизнес-логики, то от них было бы больше пользы, чем вреда.

Проблема в том, что только конечный разработчик знает, какие исключения на самом деле возможны и их надо проверить, а какие нет. Например, при парсинге url из константы на самом деле проверка исключения нафиг не нужна. А при валидации какой-нибудь структуры тот же NPE можно тоже считать проверяемым. Или в функции аллоцирующей массив на гигабайт OOM надо проверять.

Я думаю, они могли бы лучше оставить конструкцию throws, но не привязывать проверяемость исключения к его типу. Просто если исключение есть в throws, то вызывающий должен либо проверить, либо добавить в свою смгнатуру throws. А класс исключения не важен.

Язык программирования может быть любым, если этот язык - Java!

Долгой жизни, Java!

Checked exception не гарантируют, что в недрах какой нибудь библиотеки не кидается unchecked exception. Потому что необходимость проверять исключение на самом деле от контекста зависит очень сильно. А разработчик библиотеки не знает контекст вызова. И не может адекватно выбрать тип исключения для всех использований.

Вышла Java 21 LTS (комментарий)

А количество скобочек не влияет на скорость байткода, но влияет на его читаемость.

Мне думается, что проблема именно с checked exceptions как таковыми. Если почитать попытки например Блоха представить идею в основе деления на чекед и анчекед, то там смысла очень мало и очень сомнительно всё. Во-вторых, принудительность их ловли, мне думается, это большая глупость тоже. Про «заабузили в стандартной библиотеке» это довод странный, всё таки кто язык проектировал и это туда добавил и кто библиотеку писал - это один коллектив был, то есть это те же примерно люди.

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