Roger Pack
added a comment - 11/Oct/10 12:47 PM - edited Having it default to true also prevents one from, by default, being able to use multiple sub-processes to run jruby (this is what got me, today).
this code runs differently, which is a gotcha with it on by default:
(0..20).map{|n| Thread.new
{ system("jruby -e 'sleep 10'") }
}.each
{|th| th.join}
Also, it appears others have shared this opinion:
http://www.mail-archive.com/dev@jruby.codehaus.org/msg02874.html

Roger Pack
added a comment - 14/Jan/11 11:05 AM If charles' proposal for Kernel#ruby is accepted then the default should be true still? Of course, until then I think it should default to false, so +1
-r

Well there's a bigger problem here: Most Ruby libraries still do "exec" or "system" or `` using "ruby" as the command to run. That's obviously a bug in those libraries; any ruby install with a command named something other than "ruby" will fail to work properly. But what can we do?

Currently we check for "ruby" at the start of the command and then attempt to parse out the arguments and run it in-process. That keeps it in JRuby, but has the side effect of not actually running a separate process nor running "ruby", if that was the actual intent. If we turned off inproc launching completely, a system('ruby ...') call would suddenly stop running in JRuby. We could again mine out the "ruby" part and make it "jruby", but the parsing is more complicated and we'd be explicitly preventing "ruby" from being run as an external command from within JRuby.

So you see, it's actually a very sticky problem. The inproc launching, for all its faults, still seems like the cleanest way to address all the following issues:

Commands being executed as "ruby" that are intended to use the currently-executing ruby runtime (i.e. not using 'jruby' command on jruby, etc)

Many libraries and apps shelling out frequently (such as for running tests or specs) penalizing us for our slow startup if we launch a whole new JVM

I appreciate that it's confusing, but there are many challenges in changing it.

Charles Oliver Nutter
added a comment - 15/Feb/11 8:12 PM Well there's a bigger problem here: Most Ruby libraries still do "exec" or "system" or `` using "ruby" as the command to run. That's obviously a bug in those libraries; any ruby install with a command named something other than "ruby" will fail to work properly. But what can we do?
Currently we check for "ruby" at the start of the command and then attempt to parse out the arguments and run it in-process. That keeps it in JRuby, but has the side effect of not actually running a separate process nor running "ruby", if that was the actual intent. If we turned off inproc launching completely, a system('ruby ...') call would suddenly stop running in JRuby. We could again mine out the "ruby" part and make it "jruby", but the parsing is more complicated and we'd be explicitly preventing "ruby" from being run as an external command from within JRuby.
So you see, it's actually a very sticky problem. The inproc launching, for all its faults, still seems like the cleanest way to address all the following issues:
Commands being executed as "ruby" that are intended to use the currently-executing ruby runtime (i.e. not using 'jruby' command on jruby, etc)
Many libraries and apps shelling out frequently (such as for running tests or specs) penalizing us for our slow startup if we launch a whole new JVM
I appreciate that it's confusing, but there are many challenges in changing it.

Seems there are two things at play
1) it's faster to do it in process
2) it's easier on the end user to grab "ruby" command lines and parse them into jruby.

Perhaps the default behavior should be to grab "ruby" command lines and then start a whole new process using java.exe again, with correct arguments (i.e. basically just replacing "ruby" with Gem.ruby)? I'd guess the only drawback to this is the slowdown, but users could notice and avoid that by passing some other (optional) parameter like inproc or what not.

Then it would be satisfying number 2, but number 1's side effects are also eliminated?

Roger Pack
added a comment - 16/Feb/11 5:42 PM Seems there are two things at play
1) it's faster to do it in process
2) it's easier on the end user to grab "ruby" command lines and parse them into jruby.
Perhaps the default behavior should be to grab "ruby" command lines and then start a whole new process using java.exe again, with correct arguments (i.e. basically just replacing "ruby" with Gem.ruby)? I'd guess the only drawback to this is the slowdown, but users could notice and avoid that by passing some other (optional) parameter like inproc or what not.
Then it would be satisfying number 2, but number 1's side effects are also eliminated?