Добрый день!

Checkstyle ругается на "public final" поля класса. По сути он против структур данных.
Причём судя по доке выпилить это можно только вместе с контролем на просто public поля.

Кто-нибудь пробовал копнуть глубже- на уровне патчанья исходников, или плагина-фильтра?
Нет времени глубоко погружаться в это дело, но хочется избавиться от ненужного варнинга.

--
Алексей.

BlazkowiczПравильно ругается, что нет так-то? По сути структуры данных в Java делаются как immutable Java bean. Зачем поля выставлять напрямую. Ни полиморфизма потом на них не сделать, ни логики к ним прикрутить.

Мне кажется, что это вопрос вкуса. Мне не нравятся лишние геттеры. Ну может и смирюсь :)
Но интересно всё же узнать как можно обойти.

BlazkowiczAlexey TominМне кажется, что это вопрос вкуса.

Если вы сами себе небольшой стартап профессионалов высокого уровня. Если вы понимаете что такое Anemic Model и инкапсуляция а значит у вас никогда не будет кода вида Order.person.name, тогда ладно.


Ещё раз- есть такой тип данных, как структура. Там нет ни одного метода, кроме конструктора, и все поля public final.
Не понимаю, чем они так плохи, что checkstyle выдаёт _ошибку_ даже, а не предупреждение.

BlazkowiczAlexey TominМне не нравятся лишние геттеры.
Мне тоже не нравится их наличие в классах. Но как без них дебажить, я ума не приложу. Breakpoint-ы на полях нормально работают?

Зачем дебажить доступ к полям структуры? Но брякпоинты на поля в eclipse точно работают (пробовал на изменение), а в IDEA пока не пробовал- не надо было.

BlazkowiczAlexey TominНо интересно всё же узнать как можно обойти.
Дописать своё правило в checkstyle? :)

Новое правило, которое будет делать ту же проверку, кроме public final? Как-то через з..., мне кажется, решение.