Может ли с помощью ломбока конструктор required-arg сосуществовать с аннотациями @Value, @Builder и @Builder.Default?

1. Lombok создает для вас конструктор со всеми аргументами, если только вы сами не напишете конструктор, в этом случае вам нужно добавить @AllArgsConstructor. Что вы должны сделать здесь. Вы можете сделать его приватным, если хотите (@AllArgsConstructor(access = AccessLevel.PRIVATE). Он должен существовать, чтобы конструктор ломбока создавал объект. значение тоже).

2. Проблема в вашем собственном коде - вы написали свой собственный конструктор, который не устанавливает поле bravo. В общем, плохая идея также иметь свой собственный конструктор, особенно если указанный конструктор не вызывает сгенерированный ломбоком. @Builder.Default изменяет то, что делает строитель (а именно: он будет использовать это значение "X", если вы попросите строитель build(), когда для него никогда не было установлено значение для bravo). Он удаляет это "X" по ходу дела, а @Value сделал это поле final, конечно, поэтому ваш конструктор не может установить неинициализированное (потому что билдер «забирает» "X") поле final, что является ошибкой компилятора.

3. Та же проблема.

4. AllArgs и RequiredArgs — это один и тот же конструктор, поэтому ломбок пытается сгенерировать их оба, что не работает.

@Value @Builder @AllArgsConstructor class Foo {
    String alpha;
    @Builder.Default String bravo = "x";
    Foo(String alpha) {this(alpha, "x");}
    static void bar() {new Foo("y");}
}

Это то, что вы ищете. Или, что более вероятно, избавьтесь от этого конструктора и напишите:

@Value @Builder @AllArgsConstructor class Foo {
    String alpha;
    @Builder.Default String bravo = "x";
    static void bar() {return builder().alpha("y").build(); }
}

Как правило, гибридизация чего-либо в программировании не является хорошей идеей - и здесь вы гибридизуете свой подход к построению. Какой-то пользовательский конструктор для одних, строители для других. Если нужно, ладно, но это дорого. Одной из затрат является путаница (похоже, это произошло здесь). Другим является код, подверженный ошибкам: ошибки, которые нелегко найти (поскольку один человек всегда использует один способ, и, следовательно, ошибка в другом способе не находится ни в одном из их путей кода, но она есть в вашем). Третий — дебаты о стиле; если есть 2 способа сделать одно и то же, любой код произвольно выбирает способ (это плохо; делает код излишне трудным для чтения, делая одно и то же разными способами, что неверно намекает на наличие значимой разницы, которую читатель либо беспокоиться о том, или вы потратите некоторое время на поиск этого, нет, на самом деле это не имеет значения, или вам нужно руководство по стилю, чтобы указать, когда использовать какой способ. руководство, которое очень сложно сделать; большинство людей, как правило, не хотят тратить время на написание собственного правила lint).

NB: Я сказал «в целом не очень хорошая идея», а не «это всегда неправильно». Есть веские причины для гибридизации, но имейте в виду, что это дорого обходится. Следовательно, бремя аргументации лежит на авторе гибридного подхода. Им нужно объяснить, что, несмотря на значительные затраты, связанные с наличием нескольких способов сделать одно и то же, это, тем не менее, того стоит. Ваш код явно является упрощенным примером для того, чтобы задать упрощенный вопрос SO (отлично!), Так что, возможно, здесь есть веская причина. Однако в вероятном сценарии, что нет - избавьтесь от этого рукописного конструктора.