I don't like the idea of shying away from a change just because it's controversial. Sometimes its necessary to shake things up with new ideas.
+1 I'm all for pushing new ideas that make good, hard improvements to
you seem to be asking for those who advocate a builder like API here to compromise and for those who don't want such an API, to not? Thats a tough pill to swallow.
I am in fact asking for that, because largely Lucene does not adopt
the builder pattern today, the builder pattern is relatively new and
trendy, vs Lucene's codebase, and now we see it seeping in, in various
places/patches/etc. Not only is it new, it's also controversial
amongst the committers.
I think it's also reasonable because you can naturally layer the
builder API on top of a simple java APIs, but not really vice/versa.
One could create a very nice shim "Lucene builder APIs" library.
It need not be in our core APIs.
This way apps that love the builder pattern can use the builder shim;
those that don't like them can use the plain java APIs.
As other "popular" patterns try to seep into Lucene, I think we should
also take a cautious stance: we should not apply a pattern just
because it exists and has become popular; we should see strong
technical benefits to Lucene before doing so.
So, stepping back, "adopting the builder pattern in Lucene's APIs" is
the overall change I'm talking about, and I think that is a big
Also, this API feels to me to be a lot more internal, so whether or not builders could be built on top of more outward facing concepts like QueryParsers, Field/Document etc, seems a different issue?
Right this is an internal API, but for example if you build custom
queries/scorers you can still use a builder shim on top of Lucene's
core ScorerContext. It could be part of this builder shim library
Really "Lucene should adopt the builder pattern" to me is a big
change, and it's a codebase-wide, global decision. It's actually very
similar to passionate disagreements on whitespace, and this is why we
(thankfully) have a hard standard on what our whitespace looks like.
Otherwise we'd be having huge arguments about whether parens should be
surrounded by whitespace on every patch.
So net/net I don't think Lucene should adopt the builder pattern, for
internal or external APIs. Just build a shim library on top.