Solución:
Desde el @Builder.Default
la anotación está rota, no la usaría en absoluto. Sin embargo, puede utilizar el siguiente enfoque moviendo el @Builder
anotación desde el nivel de clase hasta el constructor personalizado:
@Data
@NoArgsConstructor
public class UserInfo {
private int id;
private String nick;
private boolean isEmailConfirmed = true;
@Builder
@SuppressWarnings("unused")
private UserInfo(int id, String nick, Boolean isEmailConfirmed) {
this.id = id;
this.nick = nick;
this.isEmailConfirmed = Optional.ofNullable(isEmailConfirmed).orElse(this.isEmailConfirmed);
}
}
De esta forma te aseguras:
- el campo
isEmailConfirmed
se inicializa solo en un lugar, lo que hace que el código sea menos propenso a errores y más fácil de mantener más adelante - los
UserInfo
la clase se inicializará de la misma manera que use un constructor o un constructor sin argumentos
En otras palabras, la condición se mantiene true
:
new UserInfo().equals(UserInfo.builder().build())
En ese caso, la creación del objeto es coherente sin importar cómo lo cree. Es especialmente importante cuando su clase es utilizada por un marco de mapeo o por un proveedor JPA cuando un constructor no la instancia manualmente, pero se invoca un constructor sin argumentos a sus espaldas para crear la instancia.
El enfoque descrito anteriormente es muy similar pero tiene un gran inconveniente. Debe inicializar el campo en dos lugares, lo que hace que el código sea propenso a errores, ya que debe mantener la coherencia de los valores.
Supongo que no es posible (sin haber eliminado el código). Pero, ¿por qué no implementa el constructor que necesita? Lombok está destinado a hacerte la vida más fácil, y si algo no funciona con Lombok, hazlo a la antigua.
@Data
@Builder
@AllArgsConstructor
public class UserInfo {
private int id;
private String nick;
@Builder.Default
private boolean isEmailConfirmed = true;
public UserInfo(){
isEmailConfirmed = true;
}
}
Salida de consola:
ui: true
ui2: true
Actualizar
A partir del 01/2021, este error parece estar solucionado en Lombok, al menos para los constructores generados. Tenga en cuenta que todavía hay un problema similar cuando mezcla Builder.Default
y constructores explícitos.
Otra forma es definir la tuya adquiridor método primordial los Lombard adquiridor:
@Data
@Builder
@AllArgsConstructor
public class UserInfo {
private int id;
private String nick;
private Boolean isEmailConfirmed;
public Boolean getIsEmailConfirmed(){
return Objects.isNull(isEmailConfirmed) ? true : isEmailConfirmed;
}
}