Separate Java version out of rbconfig 'arch'#9107
Conversation
The 'arch' field in RbConfig::CONFIG is used by RubyGems to name a directory where the build artifacts from extension gems list. When a gem has been installed, but its extension does not appear in this directory, RubyGems knows the extension needs to be rebuilt and warns. JRuby extensions are almost never platform-specific, so we have used a Java-related string for 'arch', with the current Java specification version appended like 'universal-java-21'. However because the version is included, any gems that have an extension build -- even if they don't actually build it on JRuby -- get associated with that exact 'arch' string. Switching to a different version of Java causes RubyGems to mistakenly think an extension needs to be built, and it warns. See ruby/rubygems#3520 for related discussions. The RubyGems team originally suggested ignoring the 'arch' version, since a similar situation affected CRuby on macOS (with an 'arch' of 'darwin-<version>'), but ultimately they only ended up patching Bundler to ignore this version. Rather than try to further modify RubyGems to ignore this version component, JRuby will omit it in 'arch' and move it to a separate 'arch_version' field users can query if desired.
|
👍 this seems the right fix to me. Regarding having the Java version available, I'm thinking having In fact I almost added them in TruffleRuby in truffleruby/truffleruby#4025 but ended up declining that PR because the other versions don't yet have a good way to get them. |
|
I would feel better about this change if CRuby did something similar to remove host platform versions from their 'arch' value as well, but I will merge this to head and see how the wider community reacts. There's a fair justification for turning all of the 'java' prefixed properties into CONFIG values, but I think I would still keep the 'arch_version' to provide a common place where the host platform version can be acquired. |
|
@eregon I'm on board with putting more "java" properties into CONFIG but it's not exactly relevant to this issue. Happy to discuss in a separate issue or PR. Merging for 10.0.3.0. |
|
Note there's a related issue for JRuby builds currently: the resolv-replace gem added in JRuby 10 (to support Ruby 3.4 standard gems) depends on the resolv gem, which means it needs to show up as a default gem. Since it is directly in our stdlib right now, RubyGems always warns about the missing extension. I'm working to switch over our build to that gem in #9108. |
2 participants
The 'arch' field in RbConfig::CONFIG is used by RubyGems to name a directory where the build artifacts from extension gems list. When a gem has been installed, but its extension does not appear in this directory, RubyGems knows the extension needs to be rebuilt and warns.
JRuby extensions are almost never platform-specific, so we have used a Java-related string for 'arch', with the current Java specification version appended like 'universal-java-21'. However because the version is included, any gems that have an extension build -- even if they don't actually build it on JRuby -- get associated with that exact 'arch' string. Switching to a different version of Java causes RubyGems to mistakenly think an extension needs to be built, and it warns.
See ruby/rubygems#3520 for related discussions.
The RubyGems team originally suggested ignoring the 'arch' version, since a similar situation affected CRuby on macOS (with an 'arch' of 'darwin-'), but ultimately they only ended up patching Bundler to ignore this version. Rather than try to further modify RubyGems to ignore this version component, JRuby will omit it in 'arch' and move it to a separate 'arch_version' field users can query if desired.