On Wed, 14 May 2025 22:31:46 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>> I know that comment already, but IMHO we can simply use `@implSpec` to >> unambiguously make clear that this method invokes `read(char[])` to allow >> optimized implementations, and it *might* in turn invoke >> `read(char[],int,int)`, but this is *not guaranteed*. A class is only >> fragile as long as we do not *document* what it will do. > > I doubt a subclass could make an optimization to the one-arg read() that it > couldn't also make with the three-arg read(). Since the subclass is required > to implement the three-arg read(), there's no benefit in specifying that this > method call the one-arg read() instead of the three-arg read(). > > However, requiring this implementation to call the one-arg read() method is > detrimental, because it precludes future optimizations that we might want to > make to this method, which might want to use the more flexible three-arg > read() method. Well, I did not say that the specific `CharSequence` *could not* have optimized both methods, I just said *it might be* like that (for whatever reason). 😉 I do not see a difference in the positive or negative outcomes whatever method we choose. The one method we call will benefit from its optimization, the one that we do not pick will miss the support for its optimization. I can't see what you like to optimize in future that is only possible with the three-arg parameters but would not be possible with the one-arg parameter. Do you have an example for this future optimization (note that the outcome shall and will ever be the *full* result due to the nature of this particular new method)? 🤔 If there is broad agreement that `Reader` implementation should *not* put optimizations *only* in the single-arg method but always should optimize the three-arg method too, we should definitively mention this decision in `Reader`'s Javadocs so implementors do know. Currently we only say that it would be *enough* to implement the three-arg method, which has a different semantic and urgence for the reader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090346089
