Новые возможности в Java версий 12 — 17

[PrinceKorwin]

Компилятор Java использует интеллектуальный алгоритм для удаления начального пробела из результирующей строки,

А если для отступов используется не пробел, а символ табуляции? Сколько пробельных символов будет в результирующей строке? И там будут пробелы или знаки табуляции?

А вообще стремное решение по мне. Ожидаю очередной виток религиозных воин на тему отступов. Тут же получается в итоге разный результат в рантайме в зависимости от того как у кого настроены отступы в IDE.

[aleksandy]

А если для отступов используется не пробел, а символ табуляции? Сколько пробельных символов будет в результирующей строке? И там будут пробелы или знаки табуляции?

На этот и другие вопросы можно найти ответы в спецификаци языка.

Вкратце, не стоит отождествлять пробел и пробельный символ.

[iamgal]

Насколько я понимаю среды разработки не заменяют пробелы на табы ибо они внутри строки.

А вообще такие строки очень удобная штука. Пользовался таким в питоне и прямо кайфовал

Вот бы ещё и плейсходеры в строки завезли по типу

f”{self.date} - {self.time}\n”

[WASD1]

Здравствуйте.
Записи (records) выглядит хорошим нововведением, делающим заголовки для меня (не-джависта) намного более читаемыми.

Но есть вопрос (он не-джависта): а зачем к каждому полю объекта в Джаве генерить геттер-сеттер и обращаться через них?
Случай, когда геттеры-сеттеры удобны, чтобы менять нижележащую логику понятен (был string address -> после рефакторинга стало TAddress address).
Но ведь удобство это "редкие случаи рефакторинга", а неудобства, это "бойлер-плейт код при создании каждого класса".
Более того: чем лучше ты знаешь свою предметную область - тем лучше ты можешь пресказать достаточно ли тут просто переменной (которую, например, можно сделать public и прямо читать-писать) или вероятность рефакторинга относительно высокая и лучше обращаться косвенно, через геттеры-сеттеры.

[DSolodukhin]

Потому что такова спецификация Java Bean.

[WASD1]

спасибо за ответ.
Но я вот прочитал JavaBeans - и написано, что это не интерфейс, а скорее соглашения (фактически код-стайл придуманный корпорацией Sun Microsystems).
Если бы это был (поддерживаемый языком \ платформой) интерфейс - вопросов нет.

А так колучается довольно сомнительный, но продвигаемый на уровне стандарта код-стайл.
Зачем ему следовать, поясните пожалуйста?

ПС
Разумность следования общим шаблонам я, разумеется, понимаю - обьясните зачем следовать JavaBeans на уровне здравого смысла.

[DSolodukhin]

Ну это не совсем код-стайл, это скорее «контракт». И нужно это для того, чтобы разные части кода, написанные разными людьми, находящиеся в разных библиотеках или фреймворках, могли взаимодействовать между собой. В современной Java это менее актуально, но если бы вы писали на JSF, например, вы бы поняли, как это работает.