On Thu, 13 Aug 2026 09:46:15 GMT, Tatsunori Uchino <[email protected]> wrote:
>> Tatsunori Uchino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove extra line in CharSequence > > My main focus is on String; the other two are secondary. I simply missed > deleting the offending line in CharSequence. I have just fixed it. Hi @tats-u, indeed @AlanBateman and I talked about this and indeed it seems preferable to back away from adding the default method to `CharSequence` and add an individual no-arg `String::codePointCount` method. It might also be useful to add a no-arg, static `Character::codePointCount` method; this should be fairly straightforward, but it occurs much less frequently than the String case. There are a couple issues with adding default methods to CharSequence that make doing so considerably complex, and in this case that complexity might far outstrip the benefits gained from doing something simpler. One big issue is compatibility, as has been mentioned a couple times in the discussion. We previously had some issues adding the `isEmpty` default method to `CharSequence`. Here's my writeup on this from a few years ago: https://stuartmarks.wordpress.com/2020/09/22/incompatibilities-with-jdk-15-charsequence-isempty/ Briefly, when adding a default method to an interface, it's insufficient to consider only potential clashes with methods of classes that implement that interface. Potential conflicts can arise with default methods on _other_ interfaces inherited by that class. That's what happened in the Eclipse Collections case. This possibility increases the risk of incompatibilities greatly, and thus it requires a correspondingly thorough compatibility analysis to evaluate the risk. The other issue with adding this to `CharSequence` is that it requires evaluating the impact on the JDK's implementations of `CharSequence`. That's why `StringBuilder`, `StringBuffer`, and `CharBuffer` are now involved. Each area has its own idiosyncrasies, robustness requirements, and performance requirements. This hardly seems worth going through to add a method to `String`! I did a quick search using SourceGraph, https://sourcegraph.com/search?q=context:global+lang:java+codePointCount&patternType=keyword&case=yes&sm=0 And the code pattern `str.codePointCount(0, str.length())` occurs quite frequently. In [one case](https://sourcegraph.com/r/github.com/cucumber/gherkin/-/blob/java/src/test/java/io/cucumber/gherkin/GherkinDialectProviderTest.java?L16-18) I ran across -- and there are probably others -- a new local variable was created for the sole purpose of calling both the `codePointCount` and `length` methods: String actual = em.getScenarioKeywords().get(0); assertEquals(1, actual.codePointCount(0, actual.length())); With the new method, this could be simplified to assertEquals(1, em.getScenarioKeywords().get(0).codePointCount()); Thus I think that adding just a no-arg `String::codePointCount` will provide most of the benefits, reduce the complexity of the code change, and increase the likelihood of this thing finally getting integrated. Sorry that we have gone around in a circle on this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-5286162632
