После шести месяцев разработки компания Oracle выпустила платформу Java SE 20 (Java Platform, Standard Edition 20), в качестве эталонной реализации которой используется открытый проект OpenJDK. За исключением удаления некоторых устаревших возможностей в Java SE 20 сохранена обратная совместимость с прошлыми выпусками платформы Java - большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 20 (JDK, JRE и Server JRE) подготовлены для Linux (x86_64, AArch64), Windows (x86_64) и macOS (x86_64, AArch64). Разработанная в рамках проекта OpenJDK эталонная реализация Java 20 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58837
а Java ME еще жива, кстати?
Навряд ли. А ведь норм платформа была. Много нормальных игр было, не то что эти помойки типа Steam
Шта?
"Я сравниваю яблоки с апельсинами, я очень умный"
Вроде всё правильно, и те и те круглые.
Вполне сопоставимые альтернативы, и то, и другое - фрукты.
Более того, такая штука, как "деньги" позволяет сравнивать что угодно с чем угодно. Я могу на оставшуюся сумму купить яблоки, или банку олифы, или батарейки для фонарика, или положить их на телефон, или приберечь на будущее.
> такая штука, как "деньги" позволяет сравнивать что угодно с чем угодноТолько если ты перепродаван товаров, а не потребитель продуктов. Голодный в лесу ни фонариком, ни билетами банков сыт не будет.
Да как сказать... Исправным фонариком можно подать сигнал SOS мимопролетающему вертолёту или обозначить своё местоположение для прочёсывающих лес спасателей.
ну яблоки лучше 🤨
Живо на промышленных устройствах.
Вполне себе жива, только в слегка изменённом названии: Java ME Embedded. Она всё также ориентирована на устройства с парой сотен килобайт ОЗУ и парой мегабайт ПЗУ. В ней нет Swing, NIO2 и всего такого, но есть (почти) прямой доступ к железу. Ну и всё ещё бесплатный SDK весом меньше 10МБ.Есть ещё Java SE Embedded — полноценная Java во всем стандартным API, но оптимизированная для маломощных устройств.
И то, и другое можно попробовать на Raspberry Pi, причём одновременно: мешать они друг другу никак не будут.
TinyGo жеж и Rust 🤭
А почему бы не просто на С++?
> просто на С++??????????
Зачем, когда есть чистый Си и Паскаль?
Вот Паскаль не надо. Совсем не надо.))) Разве что в учебных заведениях, чтоб бедным учащимся жизнь малиной не казалась.)))
Все новшества этого релиза - предварительные, инкубаторные. По-сути это релиз-пустышка.
Предварительный выпуск, осуждаемый предварительными программистами в предварительной жизни.
Пустышка это твой выхлоп, а работа с многопоточными программами улучшена. Выпуск развиваемый так что они не берут обязательства не вносить изменения способные повлиять на работу программ что может быть крайне важно банкам например или высоконагруженным сайтам.
Все новшества этого релиза - предварительные, инкубаторные. По-сути это релиз-пустышка.
А заглянуть самому в Release Notes религия не позволяет?
Посмотрел краткий анонс на 2 абзаца и составил мнение.
А то что в этом релизе закрыто около 1500 задач, помимо новинок это конечно мелочь.
Изучайте:
https://builds.shipilev.net/backports-monitor/release-notes-...
Все новшества этого релиза - предварительные, инкубаторные. По-сути это релиз-пустышка.
Поддержка Байкала есть?
Нужно больше мажорных версий, что бы производители дисков обогатились!
Такие частые обновления для такого языка как Джава просто вредны.
Я один слишком тупой, чтобы понять, причём тут производители дисков?
Чтобы скачать JDK нужен диск
Слишком многословный язык
Котлин возьми.
спасибо но нет.
это говно кроме как писать мапперы ни на что не годно.
и то на грувях их писать приятнее.а когда виртуалтреды попадут в ЛТС и вовсе не нужен станет.
брэйнфак же
Я матерится, когда пытался сделать запилить для себя издателя-подписчика на котлине и узнал, что там дженерики на самом деле фикция.Вот так нелья SomeClass: SomeInterface<T1>, SomeInterface<T2>
Плюс, структур нет. То есть, вычисления на стеке без аллокаций исключены
Плюс, там какая-то вакханалия с десятками сборочных систем и самих рантаемов. Oracle microsoft gradle openjdk dalvik android SE maven ? Там пока разберёшься...
Поэтому дотнет
> вакханалия с десятками сборочных системПоехавший, назови что то кроме мавена и градла, что используются в 99.9 % проектов.
Десятки у него лол.
>Я матерится, когда пытался сделать запилить для себя издателя-подписчика на котлине и узнал, что там дженерики на самом деле фикция.
>Вот так нелья SomeClass: SomeInterface<T1>, SomeInterface<T2>Пришел в тему Java, поругался на Kotlin.
>Плюс, структур нет. То есть, вычисления на стеке без аллокаций исключены
Зачем вам вычислять на стеке? В java есть нормальный gc.
>Плюс, там какая-то вакханалия с десятками сборочных систем и самих рантаемов. Oracle microsoft gradle openjdk dalvik android SE maven ? Там пока разберёшься...
Случайные слова написал, ну круто че. Есть сборочные системы ant, maven, gradle. Ant уже найти можно только в древности. Maven используется почти везде. Иногда люди переходят на gradle, так как больше возможностей.
Oracle, microsoft (amazon, openjdk, etc) - это вы видимо про поставщиков jdk. Берите любого, все идет через стандартизацию.
Dalvik - это виртуальная машина android, причем тут онаУ вас синдром утенка видать, раз готовы называть левые слова чтобы опорочить что-то иное.
>Поэтому дотнет
Ну что сказать, хорошая платформа, часто новые фичи идут. Жаль что Microsoft не отвязал ее от себя и решения идут все централизовано, ну и ломается совместимость иногда дико.
У языков с GC, в дизайне которых заложено 99% вещей отправлять в heap, в итоге дикая фрагментация кучи и под высокой нагрузкой становятся ощутимым влияние кэш-промахов, возникающих из-за вышеупомянутой фрагментации (нарушение принципа локальности).Разработка на языках типа C/C++, Rust отлично демонстрирует, что необходимость в куче возникает, когда нужно:
1) Держать в памяти что-то сильно большое
2) Держать в памяти какой-то shared объект, к которому должен быть организован параллельный доступ из нескольких потоков
3) Когда размер аллоцируемой памяти не может быть вычислен на этапе компиляции, поэтому нужна динамическая памятьВо всех остальных случаях, если разработчик отдает себе отчёт, что стек вызовов не безразмерный и разумно аллоцирует на стеке небольшие структуры/массивы структур, то оказывается, что чаще всего большую часть бизнес-логики можно описать, через такие вот "автоматические" переменные, которые освободят место сразу после выхода из блока кода, heap pressure ощутимо снижается -> у GC меньше работы, он меньше перемещает данные в памяти из одного места в другое и делает меньше stop-the-world.
Насколько знаю, в Java-сообществе в курсе проблемы, есть Project Valhalla, в рамках которого разрабатываются т.н. value types (по сути, "плоские" объекты, массивы которых JVM будет уметь хранить как массив структур, а не массив ссылок на объекты)/
P.S. Ближайший конкурент Java, С#, имеет ключевое слово stackalloc, которым, в общем-то, довольно успешно пользуются в чувствительных к производительности .NET-решениях.
>дикая фрагментация кучиВ нете сборка мусора сразу идет с жатием кучи. Все живые объекты плотно сидят в начале памяти, а за ними остается только свободное место. Это позволяет делать очень быстрые аллокации.
Ну допустим аллокации быстрые, т.к. до следующего GC цикла с компактификацией менеджеру кучи не нужно искать какое-нибудь свободное место подходящего размера. Но это не отменяет того, что непрямой доступ (по ссылке, которая по сути, неявный указатель) сохраняется и даже если объекты сидят в начале памяти, GC не делает их группировку по смыслу при размещении по фактическим адресам в памяти, так сказать. Т.е. допустим есть несколько List коллекций, даже если прошло сжатие кучи и все списки перемещены и "уплотнены" в начале кучи, это абсолютно не значит, что объекты не перемешаны друг относительно друга в рандомном порядке (т.к. GC работает в несколько параллельных потоков, намеренно не синхронизированных, ордеринг по размещению в памяти не сохраняется). А это выливается в то, что когда проц грузит данные в кэши, то в кэш-линиях соседствуют друг с другом данные, не связанные по смыслу. Из-за чего cache miss постоянный и связанные с ним издержки. В каком-нибудь хайлоаде с могучим RPS это имеет значение. Не зря же исписали кучу статей и исследований про data oriented programming и mechanical sympathy. Поэтому все и просят постоянно, чтобы добавили в язык "плоские" структуры и аллокацию на стеке, чтобы затрагивать хип только когда нужно, а не "почти всегда".
>Пришел в тему Java, поругался на Kotlin.это же одно и тоже почти.
В java используется maven и gradle. Kotlin dsl есть только для gradle. Даже kotlin-native использует gradle.
Примитивные типы в java хранятся в стэке. Kotlin их тоже использует, но пожелание использовать интерпретируемый язык со сборщиком мусора и отсутствие аллокации это странно. Не знаю каким образом оно работает в net, но не думаю что чем-то отличается.Один и тот же интерфейс и сразу 2 разных типа в параметрах SomeInterface<T1>, SomeInterface<T2> ? Ладно в java дженерики крайне ограниченные, но как в других то языках это должно работать?
>Oracle microsoft gradle openjdk dalvik android SE maven
Ну не знаю.... Вы точно программист, а не эксперт, тролящий глупым набросом?
> Один и тот же интерфейс и сразу 2 разных типа в параметрах SomeInterface<T1>, SomeInterface<T2> ? Ладно в java дженерики крайне ограниченные, но как в других то языках это должно работать?Я не разбираюсь в C++, но там вроде template'ы являются шаблонами кодогенерации в compile-time, т.е. чем больше у тебя шаблонов, и чем обобщение тип в параметризации тем больше размеры бинарника на выходе компилятора, потому как генерируются перегруженные методы с разными агрументами.
И если принять это за правила игры то параметризовав интерфейсы двумя разными типами, для методов использующих обобщенные типы будут сгенерированы декорации методов в интерфейсах с разными сигнатурами.
Пусть плюсовики подтвердят или опровергнут :) А что там в C# творится я не знаю.
Подтверждаю про С++ :)
> Поэтому дотнетТеперь понятна Ваша позиция.
Ждём добавление беззнаковых типов.
нафига?чего бы действительно хотелось - да это стракты.
что то вроде локальных рекордов но на стеке.
а то сейчас рекорды это по сути сахарок.
но я уже к ним привык, юзаю во всех проектах на 17.
так же как и вывод их в паттернматчинге через инстансоф
Не ради срача, а образования ради. А зачем вам стракты и почему именно в стек надо класть данные?
> Не ради срача, а образования ради. А зачем вам стракты и почемуиспользовать как кортежи.
ну как локальные переменные примитивы.
но при этом состоящие из нескольких полей которые могут быть примитивами или вложеными страктами.> именно в стек надо класть данные?
меньше мусора на кучу.
Че там, когда в жабку завезут safe chain call и оператор элвиса? и деление типов на nullable и non-nullable? Как в жабе начнешь эти вызовы в опшинали оборачивать или, прости господи, в if-ах проверять, хочется удалить JDK с компа.
Никогда. Сделать - не проблема. Но это разрушит совместимость, разделит джаву на до и после.
Глупости не говори:String! a = "abc"; //non-nullable string
String a = null; //nullable string
Хм... на первый взгляд это хорошее решение. А то обычно маркируют nullable знаками `?` и тогда миграция проблематична.
Я бы не отказался если бы такую штуку хотяб в переходную версию Java добавили, для теста.
С++ пользуй
А Грааль не начали еще встраивать? Они вроде грозились в конце 22го.
Ровно вчера скачал Жабу чтоб открывать IPMI-консоль в Палемуне. Результат - Жаба ругается на протухший сертификат (который, естественно, в прошивках не обновить), access denied, виснет насмерть, иногда утягивая браузер. Нахрен так жить. Это единственный ЯП/платформа, у которого в UI даже галочки тормозят...
Дату менять пробовал?
это в конфигах жре правится
> это в конфигах жре правитсягде конфиги жре? я тыкал javaw.exe (или как-то так), отключил все возможные проверки по сертам - и ему пофиг.
короче. если нужны аплеты - то качаешь 8 жде и отключаешь проверки ссл
а так же включаешь отключенные протоколы (типа 3дес ) в файле секурити.кфг.но тут еще нужен и старинный браузер который поддерживает аплеты.
у меня для этого стоял кажется 52 фирефокс, точнее не помню.если же там jws то и браузер не нужен
https://www.java.com/en/configure_crypto.htmlчитай тут короче про сесурити в жре
>который, естественно, в прошивках не обновитьэто кстати тоже ложь
О, ты мне можешь обновить и подписать жавный пакет в проше? Может, тогда добавишь туда фич каких-нибудь? И, или, хоть, логотип страшный поменять? (спойлер: прошивка старая, даже обновлять себя из вебки не умеет)
ну если бы можно было выгрузить и заново загрузить - то можно было бы переподписать своим сертификатом просто и все
>> просто и всеВыкорчевать прошивку. Проанализировать формат. Расчленить прошивку. Добыть модуль жавы. Декомпилировать его. Собрать. Создать адекватный серт (возможно, из утёкших в Сеть сливов?). Подписать. Собрать пошивку. Помолиться. Залить поршивку. Неполучить кирпич. Накакать кирпичей. Получить некирпич.
Ну, не сказал бы, что это хоть отдалённо относится к слову "просто".
Мне кажется, не стоит переводить changelog. Получается очень плохо.
Вообще-то вот это:if (obj instanceof Point p)
ещё в Java 16 было. А вот сейчас добавили pattern matching with deconstruction, что очень и очень круто:
if (obj instanceof Point(int x, int y))
И в switch, и даже в for оно работает.
>большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версииДатычо, правда? То-то у нас в репе штук пять разных Джав, на выбор.
Дык может ваш проект из меньшинства? :)
Разные версии джав нужны только в случае, если ваш проект завязывался на приватный api из кишков JDK, для которого никаких гарантий обратной совместимости. Либо проект опирался на deprecated вещи, типа явного вызова SecurityManager. Во многих случаях обновление JRE спокойно оставляет приложение работоспособным.
Проект использовал tools.jar, не знаю, зачем. Которого в новых Джавах нет. Потом был ещё восхитительный Jenkins, который на старой Джаве запускался, но крашился.
Посоветуйте пожалуйста современный букварь по Яве, желательно на английском. Спасибо.
https://teaching.csse.uwa.edu.au/units/CITS2200/Resources/Ja...
Спасибо.
Я думаю, для вас подойдут книги из серии "Для дурачков" (https://www.amazon.com/Java-All-One-Dummies-Doug/dp/1119986648)
Ява устарела, она сейчас исключительно в легаси проектах используется. Лучше Котлин изучай.
ЛПП. Кодеры со стажем часто недолюбливают Kotlin из-за его подхода (var/val для локальных переменных, странный сахар для делегирования, неожиданные побочные эффекты, когда сталкивается рефлексия из джава-библ и какие-нибудь фишки типа деструктуризации, которые скомпилировались в неидиоматический байткод, из-за чего у рефлекшена из third-party библ поломалась логика). Есть куча новых проектов, где используют последний LTS (Java 17) и вполне неплохо себя чувствуют на старой-доброй джаве, у которой синтаксис "палка-веревка" и все очевидно на ревью для читателя. Kotlin только разработку под Андроид под себя подмял тотально, в обычный бэкенд его не так часто берут, часто предпочитая проверенную классику, которая, тем более, постепенно учится новым трюкам.
Джависты, а джависты - подскажите, что-то типа RAII(C++) или using\IDisposable(.Net) в Jave уже есть?
try-with-resources/AutoCloseable