Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8028757

(spec str) CharSequence.subSequence improperly requires a "new" CharSequence be returned

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 8
    • Fix Version/s: 8
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Introduced In Version:
    • Resolved In Build:
      b120
    • Verification:
      Verified

      Backports

        Description

        The spec for CharSequence.subSequence says,

            Returns a new CharSequence that is a subsequence of this sequence.

        This is overspecified. For String, subSequence should be allowed to return a pre-existing instance (such as 'this' or perhaps an interned string or something) as long as it has the right value.

        This line of the specification was probably intended to apply to mutable CharSequences, as the mutability pretty much requires subSequence to return a new instance in order to avoid confusion. All the implementations of CharSequences in the JDK are mutable, except for String.

        It might be reasonable to modify the spec to be something like this:

        << Returns a CharSequence that is a subsequence of this sequence. The returned sequence must be an instance such that mutation of this sequence or the returned sequence must not affect the value of the other. >>

        This could be wordsmithed, of course. This pretty much has the effect of requiring mutable CS instances to return new copies, but String can return any instance it pleases since Strings are immutable.

        Note that the current implementation of String.subSequence() simply calls String.substring(). This in turn returns 'this' if the substring range consists of the entire String. Thus, String.subSequence violates this specification, because it does not return a "new" CharSequence in some circumstances.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  smarks Stuart Marks
                  Reporter:
                  smarks Stuart Marks
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: