С java 9 хранение строк реализовано либо в формате Latin-1 с 1 байтом на каждый символ, либо UTF-16 с 2 байтами на символ. Переход на UTF-8 проблемный из-за динамической длины символа. Но начиная с java 18, UTF-8 стала кодировкой по умолчанию для большинства стандартных API ввода-вывода. К тому же, Java появилась в 1995 году, когда UTF-16 казался стандартом для unicode. C# появился позже, когда UTF-8 начал доминировать в вебе
Приветствую. Всё же Spring Data R2DBC не дотягивает до полноценного ORM, как например Spring Data JPA. Здесь нет таких прокаченных связей между сущностями и отсутствуют managed entities. Из-за таких нюансов процесс работы с бд становится гораздо более прозрачным, но приходится платить за это дополнительными строками кода. По поводу составных ключей, на мой взгляд, они способны покрыть большую часть кейсов. Увы, ни с корутинами, ни с project loom пока опыта работы нет
С java 9 хранение строк реализовано либо в формате Latin-1 с 1 байтом на каждый символ, либо UTF-16 с 2 байтами на символ. Переход на UTF-8 проблемный из-за динамической длины символа. Но начиная с java 18, UTF-8 стала кодировкой по умолчанию для большинства стандартных API ввода-вывода. К тому же, Java появилась в 1995 году, когда UTF-16 казался стандартом для unicode. C# появился позже, когда UTF-8 начал доминировать в вебе
Да, это аналог
readonly record structиз C#, и project Valhalla действительно долгостройПриветствую. Всё же Spring Data R2DBC не дотягивает до полноценного ORM, как например Spring Data JPA. Здесь нет таких прокаченных связей между сущностями и отсутствуют managed entities. Из-за таких нюансов процесс работы с бд становится гораздо более прозрачным, но приходится платить за это дополнительными строками кода. По поводу составных ключей, на мой взгляд, они способны покрыть большую часть кейсов. Увы, ни с корутинами, ни с project loom пока опыта работы нет