buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <alex.boisv...@gmail.com>
Subject Re: Java integration
Date Sun, 21 Mar 2010 23:57:44 GMT
Personally, I'm still enjoying using MRI more than JRuby.   If it wasn't for
installation issues and getting JDK 1.6 working on some machines, I'd be a
completely happy camper.

I think Daniel illustrated well that we need more than exec("java")
functionality to retain the speed and integration we currently have.   And
if anything, I want Buildr to have better Java integration, not less, so I
would not want to go to a situation where we have to shell out to "java"
every time something needs to invoke bytecode.   I'm happy with using RJB as
lowest common denominator for what should work on Buildr in a standard
sense, and possibly using JRuby for extra features.

And while I'm a big supporter of having a fully supported, all-in-one JRuby
distro, I don't yet see what we would gain from going JRuby-only and
dropping support for MRI.   I would be fine making the JRuby distro our
recommended choice on the download page, though, since it would probably
result in better first experience.

alex

On Sun, Mar 21, 2010 at 12:34 PM, Daniel Spiewak <djspiewak@gmail.com>wrote:

> I think we rely on being able to call onto the JVM too much to do this.
> It's not just for compiler invocation.  The most creative use (in my
> opinion) is our test class detection, which works by spinning up a
> URLClassLoader and filtering specified .class files for specific attributes
> (such as name or superclass).  Of course, as with everything JVM-related
> that we're doing, we could just shell out, but that means we would have to
> eat the cost of JVM startup not once, but several times over the course of
> a
> normal build.  There are also tools like Cobertura or the *entire* Groovy
> integration layer which are fairly heavily dependent on Ant.  It would be
> annoying and tricky to enable these things through mere shell invocation.
>
> I think the main problem we're trying to solve here is the fact that RJB is
> flaky, difficult to install and causes endless compatibility issues.  I
> would much sooner solve this problem by going JRuby-only.  I mean, I like
> MRI as much as the next guy (particularly for startup), but JRuby has made
> pretty significant strides here in the most recent release.  We could do
> even better if we pre-compiled all of the relevant .rb files and encouraged
> the use of the all-in-one bundle (still supporting gem installations, but
> only on JRuby).
>
> Just to be clear, I'm not exactly a fan of this idea.  MRI support offers
> some very nice advantages (like Growl integration, startup time, etc).
> However, if we are seriously looking to get away from RJB, then I think we
> should do it by going to JRuby, rather than ditching JVM integration
> altogether.
>
> Daniel
>
> On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <atoulme@intalio.com>
> wrote:
>
> > Hi guys,
> >
> > I'd like to open a new discussion with Buildr and offer a new insight on
> > Buildr's link to Java.
> >
> > From day one, Buildr was tightly bound to Java. We use either RJB or
> JRuby
> > as the gateway to Java, and we have one common API to discuss with it.
> > We use the Java integration in critical yet well defined operations:
> > compiling is for sure one, we also run some tools directly.
> >
> > I think we could find a way to make Buildr less resilient on Java. I
> wrote
> > an experimental compiler that relies on an external javac recently here:
> >
> >
> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
> >
> > This compiler helps me as I need to use a different JDK for part of the
> > projects I have to compile.
> >
> > I think the Java integration of Buildr helps starting the JVM only once -
> I
> > also think we could support most scenarios by calling Java over a
> subshell.
> > I don't know how much more expensive it would turn out to be but I see it
> > as
> > a good option - when RJB breaks, or when JFFI refuses to load, which
> > happens
> > all too often.
> > We know the main problem of Buildr is its installation story. How about
> we
> > give a drop and run Buildr gem that just relies on the JVM by calling it,
> > instead of linking to it ? That would make for less headaches and work
> > allright on most OSes.
> >
> > I would like to make such an implementation - as time permits.
> >
> > Please let me know what you think.
> >
> > Thanks,
> >
> > Antoine
> >
>

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