Import JRuby's stringio impl

[headius]

This will eventually import JRuby's stringio implementation. Initial import mirrors how the strscan impl was imported in ruby/strscan#25. I will get the failing tests passing and make sure the gem builds properly for the java platform.

• Import and build JRuby code
• Add license disclaimer or get permission from contributors to relicense
• Pass tests
  • Three test failures remain that may not be supportable today on JRuby
• Add CI job
• Package java gem

[headius]

I have reviewed the current code and we would need confirmation from the following individuals to relicense.

Contributors listed below: please respond in a comment with the following, assuming you consent:

"I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license."

• @headius
• @kares
• @enebo
• @orikremer
• @dragonsinth
• @eregon
• @cheald

For me:

I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license.

[cheald]

I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license.

[enebo]

I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license.

[eregon]

I consent to having my contributions to JRuby's stringio relicensed under the Ruby license and the BSD 2-clause license.

[dragonsinth]

I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license.

Also.. wtf.. LOL

[headius]

@dragonsinth Thank you for your contribution! 😀

[kares]

I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license.

[headius]

I have pushed an update to stringio that fixes all but three failures, adds JRuby to CI, rebases on current master, and tweaks Rakefile and Gemfile for the JRuby extension.

The remaining three failures may need to be masked out.

• Two are testing overflow conditions near LONG_MAX that do not work properly on JRuby due to the JVM's INT_MAX size limit for arrays (such as the byte[] backing String).
• One tests encoding negotiation, and JRuby fails because we do not reject converting a UTF-8 sushi emoji into Windows-31J. This is not a bug in the stringio code... it is a bug in JRuby I have been unable to locate.

Testing this will require a new jruby-head build until we have a preview gem we can use.

Still waiting for consent to relicense from @orikremer.

I'm going to remove the draft from this because I'd like to get some input from the maintainers.

[kou]

Thanks.

I confirmed this with jruby Docker image https://hub.docker.com/_/jruby .

It seems that we have a bootstrap issue. rake-compiler requires yaml https://github.com/rake-compiler/rake-compiler/blob/master/lib/rake/baseextensiontask.rb#L11 and yaml requires stringio but stringio.jar isn't built yet.

I can fix this problem because I'm a rake-compiler maintainer. I'll do it later.

Can we build stringio-*-java.gem by GitHub Actions? It's very helpful for release process. If we can build stringio-*-java.gem by GitHub Actions, we can download and gem push it to release a new version. We don't need to prepare JRuby and javac environment (or rake-compiler-dock environment) on local.

[headius]

I'm still searching for @orikremer.

[headius]

Can we build stringio-*-java.gem by GitHub Actions?

@kou Are we doing that for the regular gem right now? It's a good idea to have it build, and when we tag off a release we'll just download and push the built gems.

[orikremer]

I consent to having my contributions relicensed under the Ruby license and the BSD 2-clause license.

[headius]

@orikremer Thank you!

All contributors have now given consent to relicense!

[headius]

@kou I pushed a commit that builds the .gem file as the last step of successful GHA workflow, and indeed ran into the rake-compiler stringio.jar issue. Other than that I think it should work fine and saving the pkg dir will allow you to download the built gem.

How would you like to proceed?

[kou]

@headius Thanks! I've released rake-compiler with a fix for this.

Now, we can build and test with JRuby.

There are some warnings and tests failures/errors: https://github.com/ruby/stringio/runs/6034412008?check_suite_focus=true

Should we fix them in this pull request or defer them for follow-up pull requests?

For building gem in CI, we need to use https://github.com/actions/upload-artifact or https://github.com/softprops/action-gh-release to upload the built gem. I can take over it because I did it in other projects.

[kou]

@hsbt Could you add me to https://rubygems.org/gems/stringio 's owners to push a new release?

[hsbt]

@kou Sure, I send an invitation to you.

[kou]

@hsbt Thanks! Accepted.

[headius]

Should we fix them in this pull request or defer them for follow-up pull requests?

@kou I believe these are failing because jruby-head still ships its own built-in stringio and will not honor the version from the gem. I mentioned that in this comment and noted that three of these tests will probably not be fixable on JRuby before release (unsupported or broken due to unrelated JRuby issues).

We will need to push a preview gem for jruby-head to start using the gem. We can do that before this PR is merged if you would like to see it closer to green first! We have done that before with io-wait to allow testing jruby-head (cc @hsbt).

[kou]

OK.
I"ll merge this and release a pre gem.

[kou]

@headius I've released 3.0.2.pre1https://rubygems.org/gems/stringio/versions/3.0.2.pre1-java but CI is still failing: https://github.com/ruby/stringio/runs/6043413008?check_suite_focus=true

Could you confirm it?

[headius]

I have pushed a PR for JRuby to use the gem: jruby/jruby#7178

Note most of these suites fail because we are finishing 2.7-3.1 features currently. When this is complete and doesn't regress, I will push a snapshot build that should get picked up by the setup-ruby process after tonight.