You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just for information, when the @builder is on private constructor and the toBuilder() is activated, there are a compilation errors because it tries to instance the builder but it is abstract class.
The builder() method is also not generated.
I don't have any elegant solution, one solution is passing the name of the concrete in the configuration of the annotation.
Think about it if you find a better solution.
Clearly, it is a nice to have fix / feature not a blocking problem.
Thank you for your useful lib and don't hesitate if you have any questions.
The text was updated successfully, but these errors were encountered:
Thinking about a potential solution, my idea is to add an additional parameter to the static toBuilder() method in the case @Builder was placed on a private method. This new parameter would be of the type of the abstract Builder class, instead of having it created inside the toBuilder() method and stored in a local variable. This should solve the compilation error. And then, in the manually-written class, either write an instance version of toBuilder(), or add a static one to the inner builder class.
Just for information, when the @builder is on private constructor and the toBuilder() is activated, there are a compilation errors because it tries to instance the builder but it is abstract class.
The builder() method is also not generated.
I don't have any elegant solution, one solution is passing the name of the concrete in the configuration of the annotation.
Think about it if you find a better solution.
Clearly, it is a nice to have fix / feature not a blocking problem.
Thank you for your useful lib and don't hesitate if you have any questions.
The text was updated successfully, but these errors were encountered: