drekbour

Note Java 10 has built-in immutable Collectors which is really useful for Value Object builders.

The other project mentioned doesn't actually implement the step-builder-pattern (it adds an @Mandatory annotation) so provides no help for a solution. We now have support for builder-validators which provide alternative...

#132 includes `Builder for an abstract pojo is itself abstract`, probably closes this issue

Will PR some [JMH](https://openjdk.java.net/projects/code-tools/jmh/) benchmarks so we can be defend against performance changes before picking this one up again. Never set it this up under Gradle before so will be...

Benchmarks added via #162. Ran the pertinent ones with `gc` profiler and get the following unsurprising results: ```` Benchmark Mode Cnt Score Error Units PojobuilderPerformance.constructViaOptionalBuilder_withOptionalProperties thrpt 140.031 ops/s PojobuilderPerformance.constructViaOptionalBuilder_withOptionalProperties:·gc.alloc.rate.norm thrpt...

FYI: was based on following (Java 8) style implementation whereby the stored value type is always identical to the pojo. ````java public Custom4BookOptionalBuilder withTitle(String value) { this.value$title$java$lang$String = value; this.isSet$title$java$lang$String...

a) I seem to broken a test in my final "this little tidy up can't break anything" commit. Will have to look into that in a day or so. b)...

I made some small changes that take a step forwards because the "proper fix" eludes us. We all know this by now :) Can my "baby steps" changes get into...

Your playground example has the same issues, specifically `AppleBuilder.withColour` completely shadows the `FruitBuilder.withColour` (as it must because it needs to change the return type). (Apple also needs directive `baseclass=FruitBuilder.class`) Extending...

PB still doesn't support this! There is no logical reason to reject "abstract Builders" because you _prefer_ interfaces. In our current code, that "builder interface" is hundreds of lines long...