Notes:

• My code formatter got a little busy adding @Override, and it removed a couple casts it deemed unnecessary. I have no problem backing out that diff clutter if you prefer!
• In the discussion on the previous PR, @benmccann mentioned adding custom parser arguments to create() calls. I have not yet done this, for two reasons.
  • First, I wasn't sure which create calls - Column, ColumnType, both, and on which calls? Looking at all the variants made me worry about method proliferation, so I wanted to hold off on any of that work until after review and discussion.
  • Second, it seemed to me that method chaining after construction might be sufficient to support all use cases without adding create() methods. We could do this PR that allows custom parsing via method chaining, and if we need parser in a create() method, we can follow on with another PR.

Looks pretty good to me. In hindsight, we should have provided a builder interface rather than all these create methods. My biggest concern with this code is (a) did you miss any create methods, so that the parser may be null at some point, and (b) will someone do that in the future when adding or modifying a create method. I agree that adding custom parser options to each create is overkill.

I just resurveyed the code and as best as I can tell:

• the ColumnType.create(name) methods all call the corresponding Column.create(name)
• all of the Column.create(name) methods either call a public constructor that calls a protected/private constructor, or call a protected/private constructor directly
• all Column classes define one or more protected/private constructors that call super() with the default parser for the column type
• AbstractColumn has a single constructor which requires a parser to be supplied; this constructor invokes setParser(parser) to initialize the field

So AFAICT there is no way to create a column with anything but the default parser for the column type. The only way to get a null parser into a column today would be to invoke column.setParser(null).

One precaution we could take is to add a preconditions.checkNotNull() to setParser() in AbstractColumn, which would cause any attempt to initialize or update a column with a null parser to fail fast.

This behavior would be approximately equivalent to what I believe would happen today should someone try to create or update a column with a null name, as such an operation would fail with an NPE when attempting to trim the name.

Rebased to current main and force-pushed.