FindBugs-детектор для атрибутов Builder NonNull Lombok

Ответ 1

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 значением в вашем примере. Тем не менее, FindBugs, вероятно, недостаточно мощный, чтобы сделать это (пока?), И я не знаю, какой пользовательский детектор способен на это.

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

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

TL;DR: Проблема может быть найдена теоретически, но FindBugs недостаточно эффективен. С другой стороны, ломбок не должен добавлять дополнительные нулевые проверки, поскольку он нарушает законные варианты использования.

Ответ 2

это может показаться как нит-кит...

• FindBugs
• Проверка валика (JSR303)
• Проверка бобов 2.0 (JSR380)

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

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

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

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

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

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

^{возможно, это может быть сделано общим для размещения многих классов - somoeone, пожалуйста, отредактируйте!}

@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) }

    }        
}