Abstract RubyString#9369
Open
headius wants to merge 1 commit intojruby:masterfrom
Open
Conversation
8234b5f to
1a98eb2
Compare
This is not a particularly good split of functionality; some methods that are ByteList-agnostic could be moved back up to RubyString and other methods that can't work without ByteList have hard errors if unexpected types show up. The goal should be as with RubyArraySpecialized subclasses, where most of the common algorithms are implemented in the parent without a dependency on any internals, and only those that require access to such internals for performance get reimplemented in the child classes. This patch sets the stage for such a move, though.
Member
Author
|
I don't believe this can happen for 10.1 given the exposure of the RubyString constructors. I will push a different PR that deprecates all of them for removal and we will hope to do this some time later. |
headius
added a commit
to headius/jruby
that referenced
this pull request
Apr 9, 2026
We would like to make RubyString abstract, so it can be represented more efficiently when containing a single character or a Java String. In order to do so, we need users to stop using the public constructors. This patch deprecates all of the constructors for removal. They will not prevent compilation, but they should show up a bit more boldly and most Java editing tools will highlight them as errors. See jruby#9369 for the attempt to abstract RubyString. This effort will be put on hold for now due to the many exposed constructors. See jruby/jruby-openssl#355 for an example of an external library that was using these constructors directly.
headius
added a commit
to headius/jruby
that referenced
this pull request
Apr 9, 2026
We would like to make RubyString abstract, so it can be represented more efficiently when containing a single character or a Java String. In order to do so, we need users to stop using the public constructors. This patch deprecates all of the constructors for removal. They will not prevent compilation, but they should show up a bit more boldly and most Java editing tools will highlight them as errors. See jruby#9369 for the attempt to abstract RubyString. This effort will be put on hold for now due to the many exposed constructors. See jruby/jruby-openssl#355 for an example of an external library that was using these constructors directly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the final of three planned abstractions for JRuby 10.1. Abstracting RubyString will allow us to more easily introduce subtypes that compactly represent single bytes or characters, efficiently wrap Java String and CharSequence, and explore alternative backing stores.