Thinking a bit outside the box here, we could use ShrinkWrap and their ShrinkWrapClassLoader which would obviate the need for JRubyClassLoader to copy files to /tmp

@rtyler JRubyClassLoader is mutable as it can add jars and can defineClass anytime. the ShrinkWrapClassLoader has no such features and is not usable as such.

the files need to stay around as any resource loading can happen any time and the classloader does not cache the whole content in memory.

using the PID to collect the jars is possible but is NO guarantee since any forking of "ruby" will reuse those jars for setting up its "forked" jruby classpath. well, it would help for those apps which do not fork.

@mkristian Yes, I agree with the ShrinkWrapClassLoader no longer being viable. In my initial experiments it's just been too simplistic.

ShrinkWrap in general however, I believe will be a viable way to replace this code, most of what I'm struggling with around it is not the code so much as learning how these class fits into the rest of the LoadService.

I think ShrinkWrap is the right way forward here, and it's not that difficult to use ShrinkWrap, just a tough task for me as a core newbie :)

@rtyler the LoadService is only part of the picture. I added some javadocs to JRubyClassLoader https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/util/JRubyClassLoader.java#L45

the JRubyClassLoader.addURL needs to work with any possible custom url protocol. since the passed in URL might not work like this: {code}new URL(url.toString()).openStream(){code} the copy to /tmp is there. some classloaders produce URLs with "special" StreamHandler which do not work after the round trip over the String. having the URLClassLoader deal with only "file:" URLs has proven to work with all kind of custom classloaders coming with j2ee or osgi.

further the URLClassLoader bits are also used to find directory entries in case there are no '.jrubydir' files on these added jars. not a big usecase IMO but was a legacy requirement to keep.

the LoadService itself is not the right place and org.jruby.runtime.load.LibrarySearcher is the better or any code which uses JRubyClassLoader.addURL

let's go the PID idea first and give more time to the ShrinkWrapClassloader idea as it is a bigger change and hard to tell where problems pop up

improved with 28f6507

closing and continue the ShrinkWrap idea here: #3361