Только сегодня начал использовать Ломбок. Пока мне это нравится, но один недостаток, о котором я не упомянул, - это поддержка рефакторинга.
Если у вас есть класс, помеченный @Data, он сгенерирует для вас геттеры и сеттеры на основе имен полей. Если вы используете один из этих методов получения в другом классе, а затем решите, что поле плохо названо, оно не найдет использования этих методов получения и установки и заменит старое имя новым именем.
Я предполагаю, что это нужно сделать через плагин IDE, а не через Lombok.
ОБНОВЛЕНИЕ (22 января 2013 г.)
После трех месяцев использования Lombok я все еще рекомендую его для большинства проектов. Однако я обнаружил еще один недостаток, похожий на тот, который был указан выше.
Если у вас есть класс, скажем MyCompoundObject.java, который имеет 2 члена, оба аннотированы @Delegate, скажем myWidgets и myGadgets, когда вы вызываете myCompoundObject.getThingies() из другого класса, невозможно узнать, делегирует ли он Widget или Gadget, потому что вы больше не можете перейти к исходный код в среде IDE.
Использование методов Eclipse Generate Delegate ... предоставляет вам те же функции, так же быстро и обеспечивает переход от исходного кода. Обратной стороной является загромождение исходного кода стандартным кодом, который отвлекает внимание от важных вещей.
ОБНОВЛЕНИЕ 2 (26 февраля 2013 г.)
Спустя 5 месяцев мы все еще используем Lombok, но у меня есть другие неприятности. Отсутствие объявленного геттера и сеттера может раздражать время от времени, когда вы пытаетесь ознакомиться с новым кодом.
Например, если я вижу метод с именем getDynamicCols(), но не знаю, о чем он, мне нужно преодолеть некоторые дополнительные препятствия, чтобы определить цель этого метода. Некоторые из препятствий - это Lombok, некоторые - отсутствие умного плагина Lombok. Препятствия включают:
- Отсутствие JavaDocs. Если я javadoc поле, я надеюсь, что геттер и сеттер унаследуют этот javadoc на этапе компиляции Lombok.
- При переходе к определению метода я перехожу к классу, но не к свойству, создавшему получатель. Это проблема с плагином.
- Очевидно, вы не можете установить точку останова в геттере / сеттере, если вы не сгенерируете или не закодируете метод.
- ПРИМЕЧАНИЕ. Этот справочный поиск не является проблемой, как я сначала думал. Тем не менее, вам нужно использовать перспективу, которая включает вид Outline. Не проблема для большинства разработчиков. Моя проблема заключалась в том, что я использую Mylyn, который фильтрует мое
Outline представление, поэтому я не видел методов. Отсутствие поиска по ссылкам. Если я хочу увидеть, кто звонит getDynamicCols(args...), мне нужно сгенерировать или закодировать установщик, чтобы иметь возможность искать ссылки.
ОБНОВЛЕНИЕ 3 (7 марта 2013 г.)
Думаю, я учусь использовать различные способы работы в Eclipse. Фактически вы можете установить условную точку останова (BP) для метода, созданного Lombok. Используя представление Outline, вы можете щелкнуть метод правой кнопкой мыши, чтобы Toggle Method Breakpoint. Затем, когда вы нажимаете BP, вы можете использовать представление Variables отладки, чтобы увидеть, как сгенерированный метод назвал параметры (обычно то же самое, что и имя поля), и, наконец, используйте представление Breakpoints, чтобы щелкнуть правой кнопкой мыши BP и выбрать Breakpoint Properties..., чтобы добавить состояние. Хороший.
ОБНОВЛЕНИЕ 4 (16 августа 2013 г.)
Netbeans не любит, когда вы обновляете зависимости Lombok в своем Maven pom. Проект все еще компилируется, но файлы помечаются как имеющие ошибки компиляции, потому что он не может видеть методы, которые создает Lombok. Очистка кеша Netbeans решает проблему. Не уверен, что есть опция «Чистый проект», как в Eclipse. Незначительная проблема, но я хотел об этом сообщить.
ОБНОВЛЕНИЕ 5 (17 января 2014 г.)
Lombok не всегда хорошо ладит с Groovy или, по крайней мере, с groovy-eclipse-compiler. Возможно, вам придется перейти на более раннюю версию компилятора. Maven Groovy и Java + Lombok
ОБНОВЛЕНИЕ 6 (26 июня 2014 г.)
Предупреждение. Ломбок вызывает легкое привыкание, и если вы работаете над проектом, в котором по какой-то причине не можете его использовать, он вас до чертиков разозлит. Возможно, вам лучше просто никогда его не использовать.
ОБНОВЛЕНИЕ 7 (23 июля 2014 г.)
Это немного интересное обновление, поскольку оно напрямую касается безопасности принятия Lombok, о котором спрашивал ОП.
Начиная с версии 1.14, аннотация @Delegate переведена в экспериментальный статус. Подробности описаны на их сайте (Lombok Delegate Docs).
Дело в том, что если вы использовали эту функцию, ваши возможности возврата ограничены. Я вижу варианты как:
- Вручную удалите
@Delegate аннотации и сгенерируйте / закодируйте код делегата. Это немного сложнее, если вы использовали атрибуты в аннотации.
- Деломбокируйте файлы с аннотацией
@Delegate и, возможно, добавьте обратно в аннотации, которые вам нужны.
- Никогда не обновляйте Lombok и не поддерживайте форк (или используйте экспериментальные функции).
- Деломбок весь свой проект и перестань использовать Ломбок.
Насколько я могу судить, Деломбок не есть возможность удалить часть аннотаций; это все или ничего, по крайней мере, для контекста одного файла. Я открыл билет для запроса этой функции с флагами Delombok, но Я бы не ожидал этого в ближайшем будущем.
ОБНОВЛЕНИЕ 8 (20 октября 2014 г.)
Если это вам вариант, Groovy предлагает большинство тех же преимуществ Lombok, а также множество других функций, включая @ Delegate. Если вы думаете, что вам будет сложно продать идею сильным мира сего, взгляните на аннотацию @CompileStatic или @TypeChecked, чтобы узнать, поможет ли это вашему делу. Фактически, в выпуске Groovy 2.0 основное внимание уделялось статической безопасности.
ОБНОВЛЕНИЕ 9 (1 сентября 2015 г.)
Lombok все еще активно поддерживается и совершенствуется , что предвещает безопасный уровень усыновления. Аннотации @Builder - одна из моих любимых новых функций.
ОБНОВЛЕНИЕ 10 (17 ноября 2015 г.)
Может показаться, что это не имеет прямого отношения к вопросу ОП, но стоит поделиться. Если вам нужны инструменты, которые помогут сократить объем написанного шаблонного кода, вы также можете воспользоваться Google Auto - в частности, AutoValue. Если вы посмотрите на их
person
Snekse
schedule
09.10.2012
javac, чтобы открыть доступ к внутреннимsun.*классам (( - person gavenkoa schedule 22.09.2017