Well, it's fine when you understand it, as you can usually get around it. I do find that allowing Java.classpath to act as if it were writable is terribly misleading, since any debugging code you add will at as if it had, indeed been modified. Fortunately I was skeptical enough to suspect this. Took a while..... :) Might help to have better documentation of the Java object.
--Ed On Oct 8, 2010, at 7:16 AM, Alex Boisvert wrote: > 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
