Aren't these constructors chained? I believe it is quite common practice to use nulls when calling a chained constructor to get a default for that parameter. If a certain type of convenience constructor is missing, a caller can pass in `null` for the parameter they'd like defaulted. It's not too far-fetched to allow this **if** there is a constructor where this parameter is omitted and is assigned a default.
If anything, the constructors IMHO should document that for certain parameters passing in `null` results in a specific default. --John On 18/08/2025 19:46, Nir Lisker wrote: > Hi all, > > In DateTimeStringConverter, NumberStringConverter, and their > subclasses, null parameters sent to the constructors are internally > converted to default values. This is not specified, but it's how the > implementation behaves. I'm working on some changes there and was > thinking about changing the behavior to throw NPEs as it makes > no sense to pass null into these and it's probably a bug more than > anything. > > The LocalDate/Time converters specified the null-friendly behavior in > their docs even though it doesn't make much sense there either. > > Are we allowed to change this? > > - Nir
