This is an attempt to fix jruby/jruby-launcher#29 and workarounds that are apparently needed by setup-ruby and the jruby-dev-builder.

It might also make sense to have bin/ruby exec bin/jruby or vice versa, rather than having three copies of the launch script, but the extra copies don't really hurt anything.

That sounds good.
A possibility is to merge this and then try on a branch or PR of jruby-dev-builder removing the workarounds if it works as intended.

try on a branch or PR of jruby-dev-builder

Except this is to be merged into jruby-9.4, and you said you don't want to support head builds of jruby-9.4 in jruby-dev-builder.

If that can be changed, I'm willing to help set it up.

Shouldn't this also be merged on master and maybe tested there first?

When we intend a fix to go into an earlier release, we merge there first and then merge forward to master for current releases. We do not merge backwards due to the large number of changes that happen on master, and cherry-picking changes makes future merges more difficult.

It could be debated this change should not be applied to 9.4, though. @enebo ???

@enebo Ok, I've rebased on current master.

I'll deploy it as a snapshot and test it in my fork of jruby-dev-builder.

Tested successfully here, with a snapshot made from this branch:

https://github.com/headius/jruby-dev-builder/actions/runs/15914550995/job/44889507971

I did think of an issue with having both bin/jruby and bin/ruby be a full launcher: jruby-launcher only overwrites bin/jruby. So, options:

1. Modify jruby-launcher to overwrite both.
2. Make bin/ruby just a small script that launches bin/jruby so it picks up the bin/jruby native binary from jruby-launcher.
3. Do the same thing but make bin/ruby the master and modify jruby-launcher to overwrite that file.

I think only option 1 is viable.

Option 2 would mean that the bin/ruby executable would remain a shell script even after installing jruby-launcher, since only bin/jruby would be overwritten. It works with a symlink because the symlink just points at bin/jruby.

Option 3 would not be backward compatible with older JRuby releases that don't redirect bin/jruby to bin/ruby.

It might also be possible to get the bin/ruby symlink into the tarball, but that seems unreliable.

I have made changes to support Option 1 above.

• Instead of copying bin/jruby.sh to bin/jruby and bin/ruby, the latter two simply exec bin/jruby.sh. That file becomes the true master launcher even when installing the native executable (on unix).
• jruby-launcher will now overwrite both files with the native executable. Since they just exec bin/jruby.sh there's no change in behavior except that they can now be used in shebang lines on non-Linux unixes.

By having both aliases exec the master script, neither of them duplicate its contents.

By installing the native executable to both places, neither will fail to work in shebang lines.

We may want to consider encouraging people to use bin/ruby as their primary way to launch JRuby in the future, and modify RubyGems to use that in shebangs instead of bin/jruby.

I'm re-pushing a snapshot without these changes to avoid breaking anyone using jruby-dev-builder nightlies, but I think almost everything is in place:

This PR:

• adds bin/jruby and bin/ruby that source bin/jruby.sh and removes copying from the build
• adds bin/ruby.bat that relaunches bin/jruby.exe.

This eliminates the workarounds discussed in jruby/jruby-launcher#29.

jruby/jruby-launcher#54:

• installs the native executable in both aliases, replacing bin/jruby and bin/ruby, but also just redirects to bin/jruby.sh.

I'm not going to mess with this too much more until we can discuss.