You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In MRI, ENV is not a Hash but a pseudo-Hash-like singleton object with all of its own methods. This is done so that all Hash-y operations actually go directly to and from the system environment via getenv and setenv.
ENV is populated at boot by first creating a Map of RubyString, and then by inserting that Map's contents into ENV itself.
This allows us to delegate some of ENV's logic to Hash, but also results in a lot of needless complexity and a visible difference from MRI.
In the case of ENV_JAVA, we do basically the same process, when we really could just go directly to/from System.getProperty/setProperty.
I propose that we fix this in a 9k release by making ENV truly just be a proxy as in MRI.
There is one possible side effect of following MRI's course: We would not cache the Ruby String instances that ENV produces, and would have to transcode to/from Java String to interact with env and property APIs.
The text was updated successfully, but these errors were encountered:
It still scares me a bit to actually twiddle the process ENV but it would make one big feature a lot simpler: environment changes during spawning.
Currently the only way we can implement those changes is to tweak the command line to use sh -c and set environment variables along the way. This obviously is unexpected when running a simple command and there are multiple bugs in the tracker related to this behavior difference.
We also have a growing separation between "JRuby at the command line" and "JRuby embedded in a larger app"; should the behavior change depending on which mode you're running in, with the CLI mode being most POSIXy and compliant?
We also have a growing separation between "JRuby at the command line" and "JRuby embedded in a larger app"; should the behavior change depending on which mode you're running in, with the CLI mode being most POSIXy and compliant?
oh right, that is a concern - sounds to me like it definitely should change (e.g. would not expect setting native env in Tomcat). maybe leaving it as is for now - as there seems to be no user complaints atm.
Well, other than the issues people have spawning subprocesses with env changes. There's at least a few of those bugs. Our "hacky" workaround of turning the command into a shell script works reasonably well.
Environment
JRuby, all versions.
Expected Behavior
In MRI, ENV is not a Hash but a pseudo-Hash-like singleton object with all of its own methods. This is done so that all Hash-y operations actually go directly to and from the system environment via getenv and setenv.
Actual Behavior
In JRuby, we have the following differences:
This allows us to delegate some of ENV's logic to Hash, but also results in a lot of needless complexity and a visible difference from MRI.
In the case of ENV_JAVA, we do basically the same process, when we really could just go directly to/from System.getProperty/setProperty.
I propose that we fix this in a 9k release by making ENV truly just be a proxy as in MRI.
There is one possible side effect of following MRI's course: We would not cache the Ruby String instances that ENV produces, and would have to transcode to/from Java String to interact with env and property APIs.
The text was updated successfully, but these errors were encountered: