Детектор FindBugs для атрибутов построителя NonNull Lombok

Lombok учитывает эти аннотации @NonNull при создании @AllArgsConstructor. Это также относится к конструктору, созданному @Builder. Это код конструктора в вашем примере:

SomeObject(@NonNull final String mandatoryField1, @NonNull final String mandatoryField2, final Integer optionalField) {
    if (mandatoryField1 == null) {
        throw new java.lang.NullPointerException("mandatoryField1 is marked @NonNull but is null");
    }
    if (mandatoryField2 == null) {
        throw new java.lang.NullPointerException("mandatoryField2 is marked @NonNull but is null");
    }
    this.mandatoryField1 = mandatoryField1;
    this.mandatoryField2 = mandatoryField2;
    this.optionalField = optionalField;
}

Таким образом, FindBugs теоретически может найти проблему, потому что в конструкторе присутствует проверка null, которая в вашем примере вызывается позже со значением null. Однако FindBugs, вероятно, недостаточно мощен для этого (пока?), и я не знаю ни одного специализированного детектора, способного на это.

Остается вопрос, почему lombok не добавляет эти проверки в методы установки сборщика (что облегчило бы FindBugs обнаружение проблемы). Это связано с тем, что совершенно законно работать с экземпляром построителя, у которого все еще есть поля @NonNull, установленные на null. Рассмотрим следующий вариант использования:

Вы можете, например, создать новый билдер из экземпляра, используя метод toBuilder(), а затем удалить одно из его обязательных полей, вызвав mandatoryField1(null) (возможно, потому, что вы хотите избежать утечки значения экземпляра). Затем вы можете передать его другому методу, чтобы он повторно заполнил обязательное поле. Таким образом, lombok не должен и не должен добавлять эти проверки null к различным методам установки сгенерированного компоновщика. (Конечно, ломбок можно расширить таким образом, чтобы пользователи могли «согласиться» на создание дополнительных нулевых проверок; см. это обсуждение на GitHub. Однако это решение остается за мейнтейнерами ломбока.)

TLDR: Теоретически проблему можно найти, но FindBugs недостаточно мощен. С другой стороны, lombok не должен добавлять дополнительные проверки на null, потому что это нарушит законные варианты использования.

может показаться, что это придирка...

• Найти ошибки
• Проверка компонента (JSR303)
• Проверка компонентов 2.0 (JSR380)

происходит во время компиляции, что очень важно в данном обсуждении.

Проверка компонента происходит во время выполнения и требует либо явного вызова в коде, либо неявной управляемой среды (например, Spring или JavaEE) с помощью создание и вызов валидаторов.

FindBugs – это статический анализатор байт-кода, который выполняется после компиляции. Он использует умную эвристику, но не выполняет код и поэтому не является на 100% водонепроницаемым. В вашем случае он следовал проверке на нулевое значение только в мелком случае и пропустил строитель.

Также обратите внимание, что при создании компоновщика вручную и добавлении необходимых аннотаций @NotNull FindBugs не сработает, если вы не присвоите какое-либо значение, в отличие от назначения null. Еще один пробел — отражение и десериализация.

Насколько я понимаю, вы хотели бы, чтобы контракт, указанный в аннотациях проверки (например, @NotNull), был проверен как можно скорее.

Есть способ сделать это на SomeClassBuilder.build() (все еще во время выполнения!), но это немного сложно и требует создания пользовательского компоновщика:

^{Возможно, его можно было бы сделать универсальным, чтобы вместить несколько классов — кто-нибудь, отредактируйте, пожалуйста!}

@Builder
class SomeObject {
  @NonNull String mandatoryField1;
  @NonNull String mandatoryField2;
  Integer optionalField;
  ...

  public static SomeObjectBuilder builder() { //class name convention by Lombok
    return new CustomBuilder();
  }

  public static class CustomBuilder extends SomeObjectBuilder {
    private static ValidationFactory vf = Validation.buildDefaultValidationFactory();
    private Validator validator = vf.getValidator();

    @Overrride
    public SomeObject build() {
      SomeObject result = super.build();
      validateObject(result);
      return result;
    }

    private void validateObject(Object object) {
      //if object is null throw new IllegalArgException or ValidationException
      Set<ConstraintVioletion<Object>> violations = validator.validate(object);

      if (violations.size() > 0) { 
        //iterate through violations and each one has getMessage(), getPropertyPath() 
        // - to build up detailed exception message listing all violations
        [...]
        throw new ValidationException(messageWithAllViolations) }

    }        
}