Skip to content

Docs: how peer builder features are already solved the Simple Builders way - #226

Merged
AndreasIgel merged 4 commits into
java-helpers:mainfrom
AndreasIgel:docs/225-feature-parity
Aug 1, 2026
Merged

Docs: how peer builder features are already solved the Simple Builders way#226
AndreasIgel merged 4 commits into
java-helpers:mainfrom
AndreasIgel:docs/225-feature-parity

Conversation

@AndreasIgel

@AndreasIgel AndreasIgel commented Aug 1, 2026

Copy link
Copy Markdown
Collaborator

Documentation: how peer builder features are already solved the Simple Builders way

Closes #225.

Why

A feature comparison against Lombok, Immutables, AutoValue, FreeBuilder and RecordBuilder found that several capabilities those libraries advertise are already supported by Simple Builders — but implemented in an SB-specific way that follows its design paradigm (augment the types you already have; never redefine their semantics). Because the "SB way" of each wasn't documented, a fresh comparison (human or AI) mistakes them for missing features. This PR is documentation only — no source or behavior changes — so those "gaps" aren't re-raised.

What changed (README only)

"How Simple Builders compares" → new subsection "Doing what other builders advertise — the Simple Builders way", with one concise entry per capability, each linking to the relevant Usage section:

  • Required fields / null-safety
  • Copy / with / toBuilder (the With interface)
  • Collection immutability (the target type's responsibility)
  • Incremental / "singular" collection API (add2X, collection builders, varargs)
  • Inheritance (inherited setters + subclass-constructor-exposed fields)

(Default values are intentionally not listed — SB has no first-class default mechanism; that missing feature is tracked in #227.)

Plus an explicit note that generating value semantics (equals/hashCode/toString) and brand-new immutable value types are deliberate out-of-scope paradigm choices, not missing features.

Usage section — two new subsections documenting inherent behavior (placed here, not in CONFIGURATION.md, because these are behaviors, not configurable options):

  • Required Fields and Null-Safety (after Validation Annotations) — a field is non-nullable when its type is primitive or it carries a NotNull/NonNull-named annotation (any package, matched by simple name). build() then enforces: constructor fields must be set and non-null; setter fields, if set, must be non-null — violations throw IllegalStateException. Includes a record example.
  • Collection Immutability (end of Collections and Nested Objects) — immutability of built collections is the target type's responsibility; SB stores exactly what the type stores and never silently wraps collections. Includes a record compact-constructor List.copyOf(...) example.

TOC updated for all three new subsections. docs/CONFIGURATION.md is unchanged.

Verification

  • git diff --check clean
  • mvn -N validate passes
  • All new internal anchors resolve against actual headings

Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
@codecov

codecov Bot commented Aug 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
Comment thread README.md Outdated
Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
Comment thread README.md
Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
@AndreasIgel
AndreasIgel merged commit 1db9918 into java-helpers:main Aug 1, 2026
5 checks passed
@AndreasIgel
AndreasIgel deleted the docs/225-feature-parity branch August 1, 2026 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Docs: document how peer builder features are already solved the Simple Builders way

1 participant