Records are not “Lombok-lite”

Recreating Lombok is not the purpose of Java record.

The purpose of Java record is to provide an explicit vehicle for transparently communicating shallowly-immutable data.

Technically, records are Java’s nominal tuple. Tuple means an ordered set of fields. Nominal means the fields have names, as does their container. Practically, you can think of a Java record as a struct on steroids.

See the official document for scope and purpose, JEP 395: Records.

So no Builder feature need be provided by default as that lies outside the scope of Java record. However, you can easily create your own Builder for any particular record class.

AI-generated

Actually, you need not write your own Builder implementation. Let a generative AI draft the code on your behalf. (Be sure to review carefully as these AIs are imperfect.)

For example:

write code for a Builder class for the Java record record Person ( String name , LocalDate birth ){}

Ecosia AI chat feature produces:

public record Person(String name, LocalDate birth) {
    
    public static class Builder {
        private String name;
        private LocalDate birth;

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder birth(LocalDate birth) {
            this.birth = birth;
            return this;
        }

        public Person build() {
            return new Person(name, birth);
        }
    }
}

That code worked for me, copy-pasted, with no edits needed.

Usage:

Person person = new Person.Builder()
    .birth(LocalDate.of(2001, Month.JANUARY, 23))
    .name("Alice")
    .build();

person.toString() // ➡️ Person[name=Alice, birth=2001-01-23]

Withers

By the way, work is underway to add “withers”, a feature to instantiate a new record object based on the payload values of another. See JEP 468: Derived Record Creation (Preview).

Jakarta Validation

You may want to use Jakarta Validation (previously known as Bean Validation) to verify the validity of your new record object’s state.

Likewise, you might use Jakarta Validation in your Builder implementation.

IDE code generation

Your IDE may have a feature for generating code for a Builder from a given Java Record.

For example, IntelliJ has a built-in feature Replace Constructor with Builder. However that does not work for Java Record. But there is a plugin for that. The Record Builder Plugin can “automatically generate builder classes for your Java Records, JavaBeans and Interfaces, allowing you to select fields and configure the generated builder”.

RecordBuilder library

RecordBuilder is an interesting project that lets you mark a Java record with an annotation. Then RecordBuilder generates code for builders and withers.

I’ve not yet tried using this library, so I cannot vouch for it.

Is Record feature in Java 16 is an alternative to builder classes?

Basically ... no it isn't.

Records provide immutability to an object, so does builder pattern.

That's not correct. The builder pattern can be applied to both immutable and mutable objects. It is actually about how objects are created rather than the nature of the objects themselves.

What are pros and cons of using record in place of builder?

Well, simply put, you can't use records as a replacement for the builder pattern ... because they do different (in fact, orthogonal) things. Here's a point by point comparison of conventional Java classes implemented with the builder pattern versus record types:

• Mutability:
  • class + builder - either mutable or immutable objects can be created
  • record - immutable only
• Validation:
  • class + builder - yes ... the builder can validate the arguments incrementally or in the build() method.
  • record - yes ... in constructors
• Supports optional parameters:
  • class + builder - yes
  • record - no ... though you can implement overloaded constructors
• Supports extends:
  • class + builder - yes
  • record - no ... though you can use default methods from an inherited interface.
• Supports internal state / abstraction:
  • class + builder - yes
  • record - no
• Less boilerplate code:
  • class + builder - yes (relative to classes implemented without a builder) and no (relative to records).
  • record - yes

The "less boilerplate" issue is nuanced. On the one hand a builder avoids the need for overloaded constructors or new calls with huge numbers of parameters. (But you need to implement the builder itself ... which is mostly boilerplate.) On the other hand a record can be implemented without any explicit methods and a simple record constructor with no body.