On Thu, Oct 7, 2010 at 7:01 PM, Ed Smiley <[email protected]> wrote:
> I found a workaround. :) > Good to hear! > You can stuff the jars that will be packaged into Java.classpath EVEN if > they don't exist (yet). > > When they DO exist, and you are checking a release or running tests, the > classpath becomes correct and it works. > It doesn't seem to have any other ill effects. Not sure why Java.classpath > needs to be set so early in the game. Is that a design flaw? > It's a design limitation, yes. First, it's due to how the JVM works with a static classpath set on startup. RJB does no magic here, it simply starts an embedded JVM and passes it the defined classpath before a Java class is invoke from Ruby. The semi-good-news: The latest version of RJB (1.2.9) now creates a new URLClassLoader right on top of the system classloader and allows new classpath elements to be added at runtime. This helps although it introduces some fragility with an additional classloader (some libraries assume/want to be in the system classloader). However, I had some issues with RJB 1.2.9 when I tried it out so I backed out the change and pushed the upgrade to later. We'll need to do some debugging before upgrading. alex
