mayton2019

Каковы нынешние реалии стандарта языка? Используются ли в каких-то моментах фишки новых версий (если это вообще возможно)? Ибо судя по всем статьям, практически большинство до сих пор сидит на восьмёрке.

Да. Это отчасти правда. Основные заказчики Java разработки - это банки. А они не любят миграции версий
без какой-то особой причины. Я работал с тремя банками и я могу сказать что большая часть кода - это
легаси. И совершенно нет никакой надежды что будет bump версии языка. Product owner-ы в таком случае
задают вопрос - "а что мы с этого будем иметь". И обычно для банка - ничего особенного. В некоторых
случаях (использование CORBA или JAXb, com.sun.*) повышение версии чревато проблемами. Что-то
может резко отвалиться в новой версии.

Самые интересные новшества после JDK8 с моей точки зрения были не в языке а в других слоях JRE/JDK (GC, FFI, vectorization, unmanaged memory). Но вы еще попробуйте эти новшества продать бизнесу. Успехов вобщем.

На какой версии лучше всего практиковаться в написании кода, да и обучаться в целом?

Да. Ты можешь брать самую последнюю LTS-версию. Брать preview нет никакого смысла. Очень
сомнительно что для учебы тебе кто-то даст в туториалах экспериментальные фичи. Скорее наоборот.

Есть ли вообще предпосылки на переход большей части энтерпрайза в ближайшем будущем (ближе к 2030) на более современную версию? Почему тезис о дорогом переходе не нивелируется тем, что за 10 лет со времён восьмёрки завезли достаточно "контента", например, новый синт.сахар и обновленный GC?

Никакого глобального перехода на самом деле нет. Потому что нет такой проблемы.
По сути проблемой например для Java 21 может стать "end of extended support" а он условно отмечен
например на 2031 год. Вы еще попробуйте доживите до этого года и попробуйте сидеть на одном проекте
столько лет.

Java может стать COBOL-ом XXI столетия. Но у нее будет даже меньше проблем чем у Кобола, потому что
байткод и стек-машина имеет больший потенциал. Тоесть пока жива концепция байт-кода и пока существуют
процессоры Фон-Нейман архитектуры, можно сказать что Java неубиваема.

Вообще не стоит вам сильно циклиться только на языке. Параллельно существуют Scala, Kotlin, Groovy, Clojure
и их само существование делает много альтернатив. Одна JVM - бесконечное число языков.

Желательно возвращать либо иммутабельные объекты (LocalDateTime вместо java.util.Date)
либо клонировать.

Если вернуть сложный объект со связями, то дальнейшее использование этого может
привести к сложным и трудно-воспроизводимым багам.

Разумеется жизнь полна исключений и тут главное чтоб вся команда разработчиков ПОНИМАЛА что
ты сделал и для чего. Иначе будут конфликты и война правок в коде проекта.

Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Главный поинт при создании immutable String - безопасность кода. Когда компиллятор точно
знает что value строки не изменится - то он может доказать много кейсов и гарантировать что
разделяемая память не будет сломана. Особенно это важно для мультипоточки. Когда
разные потоки владеют строкой и здесь сам вопрос доказательства вдруг становится очень важным.

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

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

Специально для уменьшения этой проблемы (реаллокации и копирования) был создан StringBuilder.
Это вообще не строка а как-бы мутирующий буфер куда можно добавлять в хвост строки. И в конце
когда все готово - из буфера берется иммутабельная строка и на этом работа билдера закончена.

Immutable строки - это гениальное изобретение. Оно реализовано во многих языках и платформах
и оно практически спасает разработчика бизнес-приложений от трудно уловимых ошибок.

Скорее всего коды SQL ошибок зависят от DBMS. Например я по старой памяти помню что если
в коде вы видите ORA-00001 то вы скорее всего используете Oracle и ваша ошибка
связана с нарушением Primary KEY во время INSERT/UPDATE.

Другие DBMS (Postgres/MySQL) будут иметь другие коды ошибок.