We independently built a "record companion" generator — it overlaps a lot with record-builder. Sharing the approach (and where they differ)

[ivan-velikanov]

First: thanks for record-builder. We only found it after building our own thing (DataHelper), and it was a pleasant surprise to see two projects converge on the same core idea from different directions. This isn't a "mine's better" post — the overlap is real and the differences are mostly about what problem each started from. Sharing in case the angle is useful to anyone here.

https://github.com/xyz-jphil/datahelper

The shared idea

Both are pure compile-time annotation processors (no runtime reflection, no agent) that give you immutable, value-semantic carriers with proper equals/hashCode. record-builder starts from a record and adds construction ergonomics. We started from a DTO and added a record projection plus a reflection-free metadata API. Same destination on the immutability axis; different roads.

Construction: builder & withers vs. a mutable round-trip

record-builder's builder + wither:

@RecordBuilder
public record Person(String name, int age) {}

var p  = PersonBuilder.builder().name("Ada").age(36).build();
var p2 = p.withName("Ada L.");          // copy-on-write

Our generator emits, per type, a readable interface, a writable interface, and an immutable record Person_R. The mutable fluent POJO is the builder, and a "wither" is just a round-trip:

@Data                                    // our @Data — generates Person_A/_I/_IR/_R
public final class Person extends Person_A {
    String name;
    int age = 18;                        // a plain field initializer == a default value
}

var p  = new Person().name("Ada").age(36);   // fluent build
var r  = p.toRecord();                        // immutable snapshot (Person_R)
var r2 = r.toMutable().name("Ada L.").toRecord();  // "wither": new record, original untouched

Honestly, for withers the round-trip is more general — one expression changes any number of fields with arbitrary logic in between, no per-field withX generated. The one thing record-builder does that this can't: a staged builder that makes build() un-callable until every required field is set (compile-time). The round-trip will happily give you a record with nulls. If you rely on staged builders, record-builder wins that point outright.

The part that's genuinely different: reflection-free access by name

This is the bit we built that record-builder doesn't aim at, and it's hard to appreciate until you see what it lets you write. Alongside the record, every type gets:

• typed field symbols — Person.$name (a Field<Person,String>), and a FIELDS list;
• reflection-free by-name access — getPropertyByName / setPropertyByName (with type coercion) / getPropertyType, all backed by a generated switch.

No reflection means these generic helpers — written once — work for every DTO and run where reflection doesn't: TeaVM (Java→JS in the browser), GraalVM native images.

Example 1 — bind HTTP query/form params to a DTO (one helper, every DTO, even in the browser)

// write ONCE; works for any DTO; no reflection -> runs on TeaVM/GraalVM-native too
static <T extends DataHelper_I<T>> T bind(T dto, Map<String,String> params) {
    for (var f : dto.fieldNames())
        if (params.containsKey(f))
            dto.setPropertyByName(f, params.get(f));   // "500" -> Integer, "true" -> Boolean
    return dto;
}

// at an endpoint: ?q=phone&minPrice=500&inStock=true
var query = bind(new ProductQuery(), request.params());
query.minPrice();   // real Integer 500, already coerced

To do this over a plain record, you reflect over getRecordComponents() and invoke() each accessor — which is slow, untyped, needs GraalVM reflection config, and simply doesn't exist on TeaVM.

Example 2 — field-level diff for PATCH / audit logs (works on the immutable record)

// reads only the readable interface -> accepts mutable DTOs AND records
static List<String> changedFields(DataHelper_IR<?> a, DataHelper_IR<?> b) {
    return a.fieldNames().stream()
        .filter(f -> !Objects.equals(a.getPropertyByName(f), b.getPropertyByName(f)))
        .toList();
}

var before = loaded.toRecord();     // cheap immutable snapshot
loaded.setEmail("new@x.com");
changedFields(before, loaded);      // ["email"] -> audit trail / optimistic-lock / PATCH body

Example 3 — "serialize to any sink" without a serialization library

static Map<String,Object> toMap(DataHelper_IR<?> dto) {
    var m = new LinkedHashMap<String,Object>();
    for (var f : dto.fieldNames()) m.put(f, dto.getPropertyByName(f));
    return m;
}

That one map-shaped view feeds a NoSQL document store, a key-value cache, a template engine, a signed-payload builder — anywhere, with no Jackson and no reflection. (We use the same mechanism to read/write a graph DB directly; JSON is just another sink.)

The common thread: type erasure + reflection is what normally forces you to either hand-write per-DTO boilerplate or accept a reflection cost that's unavailable on JS/native targets. Generated symbols + by-name switch access removes both.

What record-builder does that we don't

To keep this honest:

• Staged builders with compile-time required-field enforcement — we have no equivalent.
• Deeper Optional / null-handling options on construction.
• It's mature and battle-tested; ours is young.
• A single-field "with" on a deep graph round-trips through two deep copies, where a record wither shallow-copies (records share immutable sub-objects). Fine for flat DTOs, a real cost in hot paths on big graphs.

Why post this here

Mostly because the convergence was striking and the reflection-free-by-name angle might spark ideas — possibly even for record-builder (a generated component-name switch would give records the same browser/native-safe dynamic access). Genuinely curious to know your views. Either way, nice work. Record-builder inspired me that a library such as mine could also have a genuine use case, otherwise I believed it is very internal pet project kind of tool.