<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Aren't these constructors chained?</blockquote><div><br></div><div>Not all of them. There are 3 tangential creation paths for DateTimeStringConverter and subclasses:</div><div>1. Through dateStyle/timeStyle ints with an optional locale that creates the DateFormat with `DateFormat.getDateTimeInstance(dateStyle, timeStyle, locale)` (similar for subclasses). There are 4 constructors here for the combinations of: none, only style(s), only locale, all.</div><div>2. Through a String pattern with an optional locale that creates the DateFormat with `new SimpleDateFormat(pattern, locale)`. If pattern is null, it uses path 1 above with default styles and the optional locale. If you wanted to use a pattern to create this converter, passing null makes little sense. It could be surprising to get a "defaults" converter when you intended to customize the format with your own pattern to begin with. I imagine that if you couldn't get a pattern, you'd use your own int styles as a replacement.<br><div>3. Through a DateFormat that is used directly. If it's null, it checks if the pattern is null (which it will always be), in which case it uses the defaults of path 1 again (with the default locale since it's not optional here). I find it odd here too to pass null and rely on the "defaults" converter.</div><div><br></div><div>NumberStringConverter and its subclasses are similar. They have path 2 with 4 combinations: none, only pattern, and locale, and both. And they also have path 3 that falls on the default if null.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 18, 2025 at 9:06 PM John Hendrikx <<a href="mailto:john.hendrikx@gmail.com" target="_blank">john.hendrikx@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <p>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.<br>
      <br>
      If anything, the constructors IMHO should document that for
      certain parameters passing in `null` results in a specific
      default.<br>
    </p>
    <p>--John<br>
    </p>
    <div>On 18/08/2025 19:46, Nir Lisker wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi all,<br>
        <br>
        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.
        <div><span style="background-color:rgb(0,128,0);color:rgb(18,144,195);font-family:Consolas;font-size:11pt;white-space:pre-wrap"></span></div>
        <div><br>
        </div>
        <div>The LocalDate/Time converters specified the null-friendly
          behavior in their docs even though it doesn't make much sense
          there either.</div>
        <div><br>
        </div>
        <div>Are we allowed to change this?</div>
        <div><br>
        </div>
        <div>- Nir</div>
      </div>
    </blockquote>
  </div>

</blockquote></div>