buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Smiley <>
Subject Re: Good stuff in Java classpath
Date Fri, 08 Oct 2010 16:29:49 GMT
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.

On Oct 8, 2010, at 7:16 AM, Alex Boisvert wrote:

> On Thu, Oct 7, 2010 at 7:01 PM, Ed Smiley <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message