In particular edu.umd.cs.findbugs.annotations.SuppressFBWarnings, otherweise SpotBugs detects violations which normally would be ignored in generated code.

It's not possible to make SpotBugs process @Generated annotation since SpotBugs process byte-code and @Generated has source retention type.

P.S. Nice library and nice work! I use Immutables a lot so it's really nice to have similar funtionality for java records.

I find that addConcreteSettersForOptional uses Optional#of instead of Optional#ofNullable quite surprising especially since Intellij IDEA by default doesn't warn against passing nulls to javax.validation.constraints.NotNull annotated parameters. What is the reasoning behind this decision?

When addSingleItemCollectionBuilders() is enabled in options, collection types (List, Set and Map) are handled specially. The setters for these types now create an internal collection and items are added to that collection. Additionally, "adder" methods prefixed with singleItemBuilderPrefix() are created to add single items to these collections.

The generated builder looks like this: https://gist.github.com/Randgalt/8aa487a847ea2acdd76d702f7cf17d6a

cc @tmichel

Closes #73

Its still down the line (Java 17, most likely), but it would be nice to have the RecordName.With generated interface be sealed so that only the record can implement it

For #114 again.

Instead of using explicit booleans to track if a collection was changed I track it by the type of the collection. For that, I added custom mutable private collections (subclassing ArrayList, HashSet, and HashMap) to the builder. This makes it explicitly known for us whether it's "our" mutable collection or if it comes from the outside.

FOR YOUR CONSIDERATION

This is an idea that I've had for a while: being able to inject null checks and defensive copying into Java Record default constructors. While working on the idea I was able to generalize it into something that can be customizable as part of a normal build process.

See the README for complete details.

I haven't decided on whether or not to release this yet. If people find it useful I will. Use <version>34-SNAPSHOT</version> to test it.

THANK YOU

For #114

Currently the test TestCollections.testRecordBuilderOptionsCopied fails, since I had to change the signature of the __list() shim methods. The problem is, that the code as on master generates setters for collections with different signatures: If addSingleItemCollectionBuilders == true: someList(Collection<? extends ListItem> someList), but otherwise the someList parameter is of type List<...>. I didn't want to change that behavior together with the other ticket, though (see #117 ).

Java's DAG for annotations processors doesn't contain TYPE_USE annotations on the Element for some reason. However, they are on the type. So, use the type instead.

Note due to limitations of JavaPoet this doesn't fix TYPE_USE annotations on parameterized types or array components. If we want to address those we will need changes in JavaPoet which has been dormant for a very long time.

Fixes #113 Relates to #111

Sometimes I feel old and conservative and want to do things the old way.

Just kidding; We have a giant codebase built on top of Immutables.org. It makes builders with setter methods. To make our migration to records as painless as possible, it is nice to migrate without having to rename the usage of Immutables builders for thousands of classes.

Also, get* set* and is* have been idiomatic Java since "forever". Some people might prefer these prefixes, even if they do make the methods three characters longer

Hey there! I've been using your library a bit and think it's a nice improvement for records. When working with nested immutable types I've found some thing a bit cumbersome. Imagine that you have the following records:

@RecordBuilder
public record Context(int id, Counter count) implements ContextBuilder.With {}

@RecordBuilder
public record Counter(int count) implements CounterBuilder.With {}

If we want to increment the count in a context we need to do this:

var ctx = new Context(1, new Counter(0));

// I know withCounter can be used as well
var newCtx = ctx.with().counter(ctx.counter().with().counter(ctx.counter().count() + 1).build());

We need to repeat the ctx.counter() bit three times unless we want to bring in a temporary variable. It would be nice if RecordBuilder provided something that simplified mutation of members that are record or other immutable types like queues. Ideally something that allows us to add arbitrary helper methods to the builder would be nice, but maybe that's difficult to do?

Another idea would be to generate variants of the setters in the builder that takes a Function<T, T>. That allows the user to mutate the inner types. The example above would become something like:

var ctx = new Context(1, new Counter(0));
var newCtx = ctx.with().counter(ctr -> ctr.with().count(c -> c + 1).build());

The drawback is of course that it could conflict with records that have members with a type of Function.

Hi Jordan

I'm playing around with new validation opportunities that you just have implemented. Very nice :-)

Howevere, It seems to be a possible to sneak thru the validation when using the withers methods.

For example when letting RequiredRecord implement RequiredRecordBuilder.With and RequiredRecord2 implement RequiredRecord2Builder.With

I expect these two unit test to pass:

    void testNotNullsWithNewProperty() {
        var valid = RequiredRecordBuilder.builder().hey("hey").i(1).build();
        Assertions.assertThrows(NullPointerException.class, () -> valid.withHey(null));
    }

    @Test
    void testValidationWithNewProperty() {
        var valid = RequiredRecord2Builder.builder().hey("hey").i(1).build();
        Assertions.assertThrows(ValidationException.class, () -> valid.withHey(null));
    }

For the @RecordBuilder.Options(interpretNotNulls = true) I guess it just as easy to add Objects.reuireNonNull in appropriate with-methods

but how to handle @RecordBuilder.Options(useValidationApi = true) ?

We dont want to perform a full validation of the entiere object via the builders static "new" method but instead only validate the actual property.

Please let me know your thoughts around this and I'll be happy to start with an initial PR.

Regards Dan

Not sure what you think of this, my team are coming from using Immutables heavily and are fond of their FieldName.of() syntax convention for static builders.

I’m assuming my change would enable us to call a static builder like FieldNameBuilder.FieldNameOf().

When statically imported, would read succinctly as FieldNameOf()

E.g.

@RecordBuilder
@RecordBuilder.Options(
    setterPrefix = "set", getterPrefix = "get", booleanPrefix = "is", beanClassName = "Bean")
public record CustomMethodNames<K, V>(
    Map<K, V> kvMap,
    int theValue,
    List<Integer> theList,
    boolean theBoolean) implements Bean, CustomMethodNamesBuilder.With {
}

Generates With interface with incorrect method names. They shouldn't have the prefix.

Hello, The aforementioned commit is preventing me from upgrading from v33 to v34. The issue:

I have a quite simple record which should create a builder:

public record CombinedFields(
    @JsonValue String combinedField,
    List<CombinedFieldsLine> lines) implements CombinedFieldsBuilder.Bean {}

But now, the generated builder contains a setter with an undefined method (shim?)

    /**
     * Re-create the internally allocated {@code List<CombinedFields.CombinedFieldsLine>} for {@code lines} by copying the argument
     */
    @Generated("io.soabase.recordbuilder.core.RecordBuilder")
    public CombinedFieldsBuilder setLines(
            Collection<? extends CombinedFields.CombinedFieldsLine> lines) {
        this.lines = __list(lines);
        return this;
    }

It's this __list method that does not exist. Is this a bug or something I need to change in my configuration?

The purpose is to make record-builder fit for a slightly off-label use case: Generate the getter/setter/equals/hashcode/toString boilerplate for our otherwise standard Java Bean classes. We don't oppose records, actually, it's just that some libraries don't fully support using them yet.

We would like to be able to make a bean class Foo like this:

public class Bean extends FooBaseRecordBuilder {
    // We need a parameterless constructor for a Java Bean.
    // If the parent class has it but makes it private, we can't even create it here.

    // Any overrides for getters/setters go here.
    // (If there are no overrides, maybe we can configure record-builder to create Foo directly.
    // We did not pursue that venue since our team is okay with having an empty Foo class.)
}

where FooBaseRecordBuilder is generated from a FooBase interface:

@RecordInterface
// Actually this is in a @RecordBuilder.Template :-)
@RecordBuilder.Options(booleanPrefix = "is", getterPrefix = "get", setterPrefix = "set")
public interface FooBase {

    boolean isCustomizable();

    @JsonView(Patchable.class) // Probably need a @RecordBuilder.Options entry to have this on the actual Java Bean
    boolean isEnabled();
}

Aside notes:

• We do not need the generated FooRecord class.
• In the FooRecordBuilder class, we need only the default constructor, the fields, getters/setters, and equals/hashcode/toString.
• The stream is a very, very appreciated addition that will help us with some other stuff. We interact with MongoDB and Jackson, and being able to iterate over whatever fields are in an entity object is a perfect match for these. (It would be nice to have a stream that returns the getters and setters, but we have to encounter that use case yet.)

Hi, somewhat related to #122, I'd like to propose allowing collections to become nullable, because right now useImmutableCollections = true does two things

• it adds the conversion to immutable collections (awesome!)
• but also enforces that the output record can never have the collection values nullable

I'm proposing to change the behaviour based on interpretNotNulls value.

• useImmutableCollections = true && interpretNotNulls = false
  • mapping will be return (o != null) ? Map.copyOf(o) : null;
• useImmutableCollections = true && interpretNotNulls = true
  • and field is determined to be nullable
    • mapping will be return (o != null) ? Map.copyOf(o) : null;
  • and field is determined to be notnull
    • mapping will be return (o != null) ? Map.copyOf(o) : Map.of();
• useImmutableCollections = true
  • current behaviour

This should also (consistently) affect the default value for collections mentioned in #122