👍 patch however it has at least 1 problematic part :
spec/ruby is shared among Ruby impls so it should be moved elsewhere (e.g. spec/java_integration)

the other would be that stdlib files now contain JRuby specific ext - which is kind of a first but than since its an ext of a .rb library there's no other easy way to not pollute stdlib with java ext pieces (which usually live elsewhere)

@kares i don't like mucking with the stdlib this way either. Maybe the java.rb can become a "pattern" so that it's not a one-off case. Otherwise, maybe there we could add special case logic to the base implementation of to_java (which I think is in KernelJavaAddons.java) to check for a URI object.

But if everyone is ok with the java.rb I'll move the test to spec/java_integration.

we need a mechanism for adding our own definitions to the stdlib without adding them to the stdlib file itself. Unfortunately I almost feel like this would be an exercise in AOP. I can think our overrides being further up load path which would then somehow require the stdlib file. This would allow cutpoint defs before or defs after the real stdlib file is required. Without a special require in our required file we could maybe use require_relative? Bleh.

If we had a generic mechanism for this then it would be really easy to patch stdlib in cases where that code makes no sense going upstream to MRI.

marked as PENDING since we vaguely agreed the idea is good but the impl will cause headaches ...

We're going to need to cross the bridge of stdlib-sharing sooner or later, now that 2.5 is gemifying everything. People will start depending on newer versions of stdlib gems and pulling whatever's released, so they'll lose JRuby-specific bits unless we come up with an answer.

The typical way to do this, I think, is to put the impl-specific bits in separate gems, so that readline would depend on readline-mri when installing on mri and readline-jruby when installing on JRuby. But this is a complex issue, since it means readline itself would need a -java release for different dependencies on JRuby.

The other option would be for the readline gem to contain both what JRuby needs and what MRI needs. That will work for some libraries that are pure Ruby, but for libraries with exts we'll still need two separate gems.