+0 for a no arg constructor equivalent to the default format.

-1 for more constructors or making PRISTINE public. More constructors defeats the purpose of the fluent API, and PRISTINE is useless as a base format because all properties have to be defined.

+0 for a no arg constructor equivalent to the default format.

If you mean the DEFAULT format here then that achieves nothing, as the user would have to override any unwanted settings - and the use would have to know which ones to override. If the DEFAULT format were ever later updated, that could invalidate the user's format.

I meant that the ctor should be equivalent to PRISTINE or perhaps PRISTINE + CRLF.

To fit in with the fluent API, there needs to be a static method.

PRISTINE is useless as a base format because all properties have to be defined.

No, it's not useless; that's why it was created as empty.

The PRISTINE format provides a base that is untainted by existing settings, which is why it works well for creating the pre-defined public formats.

The only setting that is absolutely required is the delimiter, which is why I suggested providing a ctor which takes the delimiter as its only parameter.

As I see it, there are the following possibilities for creating a new basic format using : as the delimiter.

fmt1 = new CSVFormat(':');
fmt2 = new CSVFormat().withDelimiter(':');
fmt3 = CSVFormat.PRISTINE.withDelimiter(':');
fmt4 = CSVFormat.newInstance(':');
fmt5 = CSVFormat.newInstance().withDelimiter(':');

Obviously the constant name PRISTINE can be changed, or the newInstance() method could be renamed.

As it is now it is not possible to have a format w/o an encapsulator,thus isEncapsulating() always is true.

Being forced to use an API style (fluent or other) is oh so lame.

Let's just make the ctor public. It does not break the fact that the object is immutable.

Being forced to use an API style (fluent or other) is oh so lame.

Not sure what you mean by that. Do you mean being forced to use a single style is lame?
If not, I don't see how it's possible to design an API that is totally style-free - just as every speaker has an accent.

Let's just make the ctor public.

The problem is that the DISABLED char then also has to be made public.
As it stands, the char is a hack; exposing it is a bad idea. Ideally it should be eliminated.
And it is very messy using the ctor directly. Try it.

It's still not all that easy to create a simple CSV format with only a delimiter, which was the intent of this JIRA.

I think there needs to be a ctor of the form

public CSVFormat(char delimiter)

I'm not sure it makes sense to allow a Character delimiter to be null either.

Nor am I happy with the new multiple-parameter ctor; too many params with the same type. Dropping it would force the use of the .withXXX methods, but they are much clearer than using positional parameters.

Good points, must ponder some more... with adding back the DISABLED nastiness.

I think it's now sorted:

Added ctor with single char delimiter parameter; that solves the original issue, and also allows PRISTINE to be private.

Restored DISABLED char, but as a private constant only used in the PRISTINE constant.

The DISABLED char is now not needed externally.