For years we have struggled to find a good way to handle Ruby resources inside jars. Simply using the JarFile APIs is often too slow, and delegating to URLClassLoader does not improve matters. In JRuby 1.7, we introduced caching logic into JRubyClassLoader for runtime-bound jars, which helped load times significantly, but it depended on URL handlers that are not compatible in all environments. JRuby 9k now has no caching of jar contents, and as a result we see issues like jruby/jruby#4185 where "fat jar" applications take significantly longer to load.
From my reading of Shrinkwrap docs, it could provide for us the following features:
Cached loading of jar contents, both from filesystem and nested within other jars.
URL protocol handling for those nested contents, to wire into normal classloading logic.
Tar and tar.gz support, opening up the possibility of running Ruby gems directly from .gem files.
We should explore whether Shrinkwrap could help solve our many resource-loading problems.
JRuby+Truffle has been experimenting at using Ropes plus immutable byte wrappers to implement more-efficient string mutation (among other benefits of ropes). Given the success thusfar, it seems like the same techniques could be applied to JRuby classic, potentially sharing the same implementation.
For this project, we would like to try to adapt the JRuby+Truffle ropes implementation for JRuby classic. This would involve packing more code range + encoding logic into ByteList, making ByteList itself extendable, and making appropriate changes to RubyString to work with rope-based ByteList trees.
JRuby+Truffle is experimenting with implementing a proper Ruby C API using Sulong (LLVM atop Truffle) and clever redirection of API calls back into the VM. This approach may have less overhead than our previous attempt to implement the C API entirely in JNI.
For this project, we would like to attempt to adapt that work to non-Truffle JRuby "classic", so we can share more of the code and both see some benefit from having C exts run.