<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">There's a lot more thinking required before considering adding new APIs like this. It requires thinking about new developers writing toy programs that could easily be confused by two methods that appear to do the same thing. Also needs taking a broader view on how it works with other locale sensitive APIs.<br></blockquote><div><br></div><div>One of the important reasons why I am so eager to have new APIs is to solve the problems caused by toLowerCase()/toUpperCase() for new developers.</div><div><br></div><div>At present, if we want to teach new developers how to convert between uppercase and lowercase, we have two options:<br></div><div><br></div><div>* Tell them to use toLowerCase()/toUpperCase()</div><div><br></div><div>This is a concise choice, but the learners often do not realize the true meaning of these methods.<br></div><div><br></div><div>As mentioned earlier, these two methods are often misused in most cases.<br></div><div>If we teach like this, learners may write more problematic code in the future.<br></div><div><br></div><div>* Tell them to use toLowerCase(Locale.ROOT)/toUpperCase(Locale.ROOT)</div><div><br></div><div>This is the right choice, but unfortunately, it is very complex.<br></div><div><br></div><div>Its meaning is not as concise and intuitive, and we have to encourage users to learn about Locale earlier.</div><div><br></div><div><br></div><div>The correct writing is lengthy and not intuitive, while problematic writing is actually shorter.<br></div><div>Short but problematic writing and lengthy but correct writing may cause confusion for users.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> It requires thinking about new developers writing toy programs that could easily be confused by two methods that appear to do the same thing.<br></blockquote><div><br></div><div>Due to the above reasons, I think what you said is completely reversed.</div><div><br></div><div>What will cause confusion to users is the current situation, and the new APIs will solve these issues.</div><div>The new API will provide a short and correct writing that is intuitive and can maintain consistency with the semantics of compareIgnoreCase/equalsIgnoreCase.<br></div><div>For toLowerCase()/toUpperCase(), we just need to tell the user that they are just legacy issues and never use them.<br></div><div><br></div><div><br></div><div>I understand that Java 21 is around the corner and you have a lot of work to do, so I'm sorry for taking up so much of your time.<br></div><div>But for this issue, I think it really needs to be corrected. If new APIs cannot be added in Java 21, it means that correcting these legacy issues in the community will take at least two more years.</div><div>I earnestly request that you pay more attention to this issue, and I am extremely grateful.<br></div><div><br></div><div>Glavo</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 16, 2023 at 3:07 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.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">

  
  <div>
    On 15/04/2023 13:39, Glavo wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">:<br>
        <div><br>
        </div>
        <div>I've detailed the reasons for introducing a new API
          earlier, and I hope you'll take a look at it:<br>
        </div>
        <div><br>
        </div>
        <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
          <div><a href="https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html" target="_blank">https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html</a></div>
        </blockquote>
        <br>
      </div>
    </blockquote>
    There's a lot more thinking required before considering adding new
    APIs like this. It requires thinking about new developers writing
    toy programs that could easily be confused by two methods that
    appear to do the same thing. Also needs taking a broader view on how
    it works with other locale sensitive APIs.<br>
    <br>
    In your list, auditing the usages in the JDK to identify usages
    where it should be using Locale.ROOT instead of Locale.getDefault
    would be helpful.<br>
    <br>
    -Alan.<br>
  </div>

</blockquote></div>