Проект Lombok, или Объявляем войну бойлерплейту

Тоже вариант. Вопрос выбора заключается лишь в необходимой функциональности и плате за неё. Мы обнаружили, что для наших целей Lombok убивает именно то, что нужно, и не требует смены парадигмы, стиля кодирования или привязки к инструментам. Переход на альтернативный JVM-язык — тоже решение проблемы, но это достаточно серьёзный шаг. Особенно если этот язык привязан к конкретной среде разработки, что в нашем случае недопустимо.

он как groovy? Может быть внутри джава классов? Или нет?

На Scala сейчас активно смотрим, но ввиду его сложности и необходимости менять парадигму пока остерегаемся применять где-либо, кроме тестов и служебного кода. Kotlin ещё явно не готов к продакшну. А с переходом на Xtend пришлось бы отказывать разработчикам в свободном выборе IDE и пересадить всех на Eclipse, чего мы пока что стараемся избегать.

Спасибо за наводку. Вообще, от Groovy в своё время остались не очень хорошие впечатления в плане производительности, требований к памяти и скорости разработки. Возможно, Groovy++ может решить часть этих проблем, хотя пока что он производит несколько «сырое» впечатление.

Да, это препроцессор аннотаций, и он генерирует весь код, который в любом случае пришлось бы писать. Почти всю функциональность он реализует на этапе компиляции проекта. В рантайме библиотека lombok.jar не нужна, соответственно, никакого влияния на производительность она не оказывает.

Кажется, единственной функцией, которая требует включения библиотеки в рантайм, является перехват исключений с помощью @SneakyThrows. Но к этой функции я отнёсся с осторожностью и пока решил не применять в продакшне. Хотя я не ожидаю каких-либо проблем с производительностью и в этом случае.

1. Всё верно, но Lombok позволяет указать геттеры и сеттеры отдельно для каждого поля, а если в аксессоре требуется какая-то дополнительная функциональность — мы просто убираем соответствующую аннотацию с поля и пишем этот аксессор вручную.

2. Всё так, но, как я сказал в самом начале статьи, наибольшие проблемы причиняет не генерация бойлерплейта, а его поддержание в актуальном состоянии. Например, добавили поле — нужно не забыть перегенерировать equals и hashCode, вставить его в конструктор, написать геттеры. Это всего лишь один из способов решения проблемы, которая, возможно, и не «адская», но, тем не менее, существует.

3. Я бы не сказал, что это какая-либо прослойка. Это, скорее, кодогенератор. Конечно, любая дополнительная библиотека в проекте добавляет сложность. Но большой плюс Lombok заключается в том, что он не нужен в рантайме.

Похоже библиотека не совместима с aspectj-maven-plugin. Из-за этого плагина в классах отсутствовали сгенерированные геттеры. Отключил aspectj-maven-plugin, получил следующий код после декомпиляции:

    private final AtomicReference map = new AtomicReference();

    public Map getMap()
    {
        AtomicReference value = (AtomicReference)map.get();
        if(value == null)
            synchronized(map)
            {
                value = (AtomicReference)map.get();
                if(value == null)
                {
                    Map actualValue = initMap();
                    value = new AtomicReference(actualValue);
                    map.set(value);
                }
            }
        return (Map)value.get();
    }

В библиотеке присутсвует утилита delombok, которая позволяет преобразовать любой исходник к тому виду, в котором он будет скомпилирован. Подробно её работа описана здесь. Например, вот так можно преобразовать одиночный файл:

java -jar lombok.jar delombok -p MyJavaFile.java

Да, возможно, вы правы. С другой стороны, когда в языке появляются стандартные средства расширения функциональности компилятора (препроцессинг аннотаций), понятие «корректного кода» несколько размывается.

У меня вроде изменился. Я создал в качестве теста такой класс:

import lombok.extern.log4j.Log4j;
@Log4j
public class Test {
    public static void main(String... args) {
        log.info("lol");
    }
}

Затем выполнил:

java -jar lombok.jar delombok -p Test.java

Утилита вывела в консоль следующее:

error: package org.apache.log4j does not exist
error: package org.apache.log4j does not exist
// Generated by delombok at Thu Apr 19 20:27:33 YEKT 2012

public class Test {
	private static final org.apache.log4j.Logger log = org.apache.log4j.Logger.getLogger(Test.class);
	
	
	public static void main(String... args) {
		log.info("lol");
	}
}

Ошибки связаны с отсутствием log4j в classpath, но если учесть это при запуске утилиты, то проблем быть не должно.

Никаких особых проблем во время дебага под IntelliJ IDEA я не обнаружил. Например, вызов сгенерированного аксессора корректно «прошагивается», хотя войти внутрь метода, конечно, не получится.

В Java 6 появился так называемый Pluggable Annotation Processing API.
Он позволяет определять процессоры аннотаций, которые подключаются автоматически на этапе компиляции проекта. Достаточно включить процессор в classpath.
Пример см. здесь.
Точно так же, например, работает генератор метамодели в JPA.

Приватная реализация, публичный интерфейс — это в самом общем виде принцип инкапсуляции. Для полей объекта в Java он реализуется с помощью аксессоров.