Релиз Java SE 14

Ура! Наконец-то! (Продолжает сидеть на 8-й)

Ну что скажут специалисты? Джава умирает или живет и здравствует?

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

Порты для Solaris и платформ на SPARC объявлены устаревшими и могут быть исключены в будущем

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

мда. пффф, ну хорошо наверное, что зато там тройные кавычки и всё такое.

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

Энтерпрайз живет, причем живет на несвежей java8, облизывается на java11 и вообще люди ленивы и инертны чтоб взят и уйти от жабы. За пределами банков и корпораций, в публичных сервисах и стартапах скорее всего жаба не так популярна.

а что случилось с джавами 9 и 10? (и 12 и 13?)

Они там что, ебанулись что ли - в год по релизу? Отберите Джаву у Оракла, в конце концов.

LTS 8 и 11, все остальные имеют полугодовой релизный выпуск с соответствующий поддержкой.

В год по два релиза, вообще-то.

но я хотел, чтобы это говнище сдохло

Почему, интересно?

Вообще надо поступить как с TeX

Кому надо? И зачем?

На предварительной основе представлены записи с ключевым словом record. Записи автоматически получают методы equals, hashCode, toString, геттеры к членам записи и конструктор.

Оо, нормально

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

Моё мнение - заморозить стандарт, принимать только исправления безопасности.

Но зачем, если есть Scala? Зачем из Джавы делать Скалу?

Потому что почему бы и нет? Будет куча бизнес ситуаций где это будет удобно

Будет куча бизнес ситуаций

Это джава сленг? Бизнес-переменные, бизнес-циклы, бизнес-классы, бизнес-константы.

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

Это как делать станок ЧПУ из молотка

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

Я думаю такого ПО дохрена и больше. На одном из них мы сейчас пишем.

В основном это шлак пожирающий тонны памяти, процессорного времени и нервов.

У меня вот телеграм жрет 800-1000Mb. Написан на c++ и Qt.

телеграм жрет

интересно как ты этого добился. у меня не более 100мб.

Это джава сленг? Бизнес-переменные, бизнес-циклы, бизнес-классы, бизнес-константы.

Код покрывает некоторый бизнес-процесс с бизнес объектами, все остальное, всякие преобразователи одного в другое, фабрики, адаптеры, серелизаторы это все техническая сторона, плюс язык добавляет синтаксический шум, геттеры/сеттеры, обработка исключений, скобочки, лямбды. Бизнес требования постоянно меняются, потому доку писать бессмысленно, нужно сразу код близкий к бизнес процессам, чтоб было более менее понятно. В общем в коде есть некоторое полезное действие и есть куча церемониального кода вокруг, и этот record уменьшает количество обязательного кода не имеющего ценности с точки зрения бизнес-смысла.

Scala категорически не подходит для использования в энтерпрайзе.

Обоснуй

На предварительной основе представлены записи с ключевым словом record. Записи автоматически получают методы equals, hashCode, toString, геттеры к членам записи и конструктор.

Вкусно, датаклассы в яве всегда боль и тонны пустого кода

Улучшено описание ошибок NullPointerException.

Типа use the fucking Optional?

Скала намного хуже поддерживается из-за тонны наркоманских фич. По крайней мере так говорят.

Что сломали-то? Очередная белка-истеричка на ЛОРе? Алсо, стандартом нынче является HotSpot, которая опенсурс во все поля, Оракл лишь как основной контрибьютор. Кому не хочется – зоопарк от Апача Гармонии до Азула, выбирай не хочу.

Перестаньте читать газеты перед едой. Прочитайте там про Spring Boot, Deeplearning4j и прочие современные библиотеки под современные проблемы, которые аналогами (пайтон, например), решаются менее производительно (не говоря про код, но это холивар о фломастерах)

Джава умирает или живет и здравствует?

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

Ненависть становится настоящей, когда приходится с этим работать. Был бы рад с этим никогда не сталкиваться, но увы.

а почему 11я не приживается?

Прочитайте там про Spring Boot, Deeplearning4j и прочие современные библиотеки под современные проблемы

Ты хотел сказать «и прочие современные проблемы»

а почему 11я не приживается?

Модулизация, жаба класспас поделили на множество частей и назвали их модулями. Модуль должен содержать инфу с перечнем того какую информацию о классах можно прочитать через рефлекшн. Тот же спринг активно использует рефлекшн. Потому вместе с переездом на jdk11 нужно обновлять все зависимости которые должны подключаться спрингом. Просто так поднять версии зависимостей сложно, так как везде есть небольшие ломающие изменения.

Вообще изи, для этого достаточно им пользоваться. У тебя, скорее всего, несколько текстовых сообщений в день, плюс ты, скорее всего, смотришь без shared memory.

https://imgur.com/a/DMnzeAZ

Это не какая-то течка, это его обычное потребление у меня. Иногда до гига разжирается. Такие дела.

телеграм жрет

интересно как ты этого добился. у меня не более 100мб.

Обновился до последней версии, видать. У меня Телеграм спокойно себя ведет, но иногда взбешивается и поедает всю память и всё процессорное время.

Это неправда. Модуляризация отключается одним флагом. По факту она сейчас никому не нужна и никто её не использует. Это никак не мешает использованию 11+ джавы. Spring даже с Java 15 работает без проблем, не то, что с 11.

Даже если и так, в новой jdk выпилили всякие внутренние вещи типа sun.misc.Unsafe которыми пользовались некоторые зависимости, не помню какая конкретна, может spring, может orm, может оба, потому сразу их нужно обновлять с переходом на новую jdk, а ломающие изменения никуда не делись, нужно дебажить и переписывать части чтоб совершить переезд на новые мажорные версии фреймворков и библиотек.

Не, если ты проект не держишь в нормальном состоянии, это понятно. Зависимости нужно обновлять. У меня тоже такой проект есть, который на Wicket 1.5.13 работает и обновлять его это боль. Но это не нормальная ситуация, это называется технический долг и когда-нибудь его придётся платить. Если бы его каждый год обновляли, проблем бы сегодня не было. Хочется верить, что это не такая распространённая ситуация. Такие проблемы могут быть из-за банального обновления версии байткода, когда библиотека не может распарсить байткод нового класса и у тебя всё поломается, пока не обновишь эту библиотеку. Если память не изменяет, у меня подобное было как раз при переходе с 7 на 8.

я понял. постепенно переходить на 9-10 нельзя потому что не лтс, а перейти на 11 - сломана обратная совместимость. про то как библиотечка парсит байткод и не может распарсить - это вообще жесть.

p.s. сейчас вообще остались какие-то язычки на которых можно что-то написать так чтобы хотя бы 10 лет это можно было бы не трогать?

captcha: bicycles

Пора бы закрыть вкладку с лорчиком, ведь он на львиную долю состоит из джавашлака, и работает зараза…

javascript не java

А кто тебе говорит про javascript? ЛОР-движок написан на Java.

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

На современных компьютерах это не так. Старые приложения на Java не стали жрать больше памяти, а вот новые приложения на C++/Rust в разы превосходят по потреблению памяти старые приложения на Java. Теперь уже мало 16 ГБ для компиляции Chromium — частично уходит в SWAP. Чтобы найти такое приложение на Java, которое бы потребляло больше 4 ГБ оперативки — это надо постараться. А вот C++/Rust Firefox с десятком-другим вкладок легко выжрет.

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

Не держим таких.

ЛОР - очень приятно исключение, как и продукты jetbrains.

Покажи мне браузер на Java, который будет жрать меньше лисы на одинаковом наборе вкладок.

Я бы поставил на то, что понемногу будет вытесняться kotlin’ом.

Легко. Можно часто слать гифки. Насколько я понимаю, все гифки из истории сохраняются прямо в оперативе. Гиг гифок - легко.

Это не сфера применения джавы.