Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner

XMLWordPrintable

    • Type: CSR
    • Resolution: Unresolved
    • Priority: P4
    • 27
    • Component/s: core-libs
    • None
    • behavioral
    • minimal
    • Hide
      **Spec**: As the specification is **not** changed, the method's interface is 100% backwards compatible, hence considered **risk-free**.

      **Impl**: Initial reviews performed by Alan Bateman and Chen Liang did not identify any *obious* implementation incompatibilities or negative impacts:

      * Chen's Review: "The reader becomes the source field, which is only used in Scanner.readInput apart from closing; readInput uses buf in a non-thread-safe way, so I think it is reasonable for readInput to operate on a non-thread-safe source too.
      In addition, now StringReader is just a synchronized wrapper of Reader.of. **So there should be minimal impact from this change.**"

      * Alan's Review: "sync close is one area where StringReader and the Reader returned by Reader.of(cs) have different behavior. At the same time Scanner is specified to not be thread safe. So on the surface, I think it should be okay, and anything relying on concurrent usage or async close of a Scanner may already broken if it doesn't use external synchronization. **I think the compatibility impact for the CSR will be low.**"
      Show
      **Spec**: As the specification is **not** changed, the method's interface is 100% backwards compatible, hence considered **risk-free**. **Impl**: Initial reviews performed by Alan Bateman and Chen Liang did not identify any *obious* implementation incompatibilities or negative impacts: * Chen's Review: "The reader becomes the source field, which is only used in Scanner.readInput apart from closing; readInput uses buf in a non-thread-safe way, so I think it is reasonable for readInput to operate on a non-thread-safe source too. In addition, now StringReader is just a synchronized wrapper of Reader.of. **So there should be minimal impact from this change.**" * Alan's Review: "sync close is one area where StringReader and the Reader returned by Reader.of(cs) have different behavior. At the same time Scanner is specified to not be thread safe. So on the surface, I think it should be okay, and anything relying on concurrent usage or async close of a Scanner may already broken if it doesn't use external synchronization. **I think the compatibility impact for the CSR will be low.**"
    • Implementation

      Summary

      I propose to change the implementation of java.util.Scanner's constructor from using StringReader to using Reader.of(String).

      Problem

      Scanner's JavaDocs explicitly claim that Scanner is not synchronized:

      * <p>A {@code Scanner} is not safe for multithreaded use without
* external synchronization.

      Compared to the non-synchronized Reader.of(String) implementation, StringReader's implementation could be potentially less efficient, as it is synchronized.

      Solution

      public Scanner(String source) {
    this(Reader.of(source), WHITESPACE_PATTERN);
}

      Specification

      The specification of java.util.Scanner is not modified.

            Assignee:
            Markus Karg
            Reporter:
            Markus Karg
            Roger Riggs
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: