I think that most of our JRuby 1.5 incompatibilities are superficial.
I've
seen a couple JIRA issues reported, but nothing too serious. If that
were
the only thing holding us up, I would vote that we move forward.
Unfortunately, as you pointed out, Windows 7 doesn't seem to like us
very
much. I'm sure RJB has something to do with it, but it's certainly
not the
whole story. We're a build system. That means we have to deal with file
permissions, locking, etc. All of that nasty stuff that drives people
away
from Ant; they come to us because we're supposed to deal with it for
them!
I don't think we're ever going to be able to get away from that. We
could
probably do more to separate out some of the platform-specific bits
though,
and that would certainly help. It's never going to be a write once, run
anywhere situation though.
As for RJB in general, I don't see a way to get away from it without
completely dropping support for MRI, and there's still a lot of
resistance
to that idea (quite a bit of it from myself). I love JRuby as much as
the
next guy (probably more), but its startup time is just too high for the
quick, one-off invocations required by a build tool. With that said,
if we
went JRuby-only, I think most users (myself included) would get used
to it.
After all, Buildr under JRuby is still a whole lot faster than Maven 2.
:-) It's also worth pointing out that there are certain features (e.g.
Growl support on OS X) which only work under MRI and are unlikely to
ever
function under JRuby (though I do have some ideas on that front).
Another option might be to roll our own RJB, something which gives us
more
flexibility and greater control over that pesky C backend. This is
actually
something that I've done in the past (though my project wasn't as
featureful
as RJB), and I can positively say that it's not a trivial
undertaking. I'm
quite certain that we could do better than RJB, but it would take
time and
effort, two things which might be better spent on Buildr itself. And
given
the innate limitations of a bridge-based solution, we may *never* be
able
to
catch up to what JRuby can do right now.
I hate RJB too, but I don't see a lot of options. One thing which
might be
worth pursuing post-1.4 is a streamlined all-in-one JRuby based
distribution
which doesn't load RubyGems by default (as Charlie suggested). If we
could
get JRuby-based *perceived* startup time to within 200-300% of what
MRI is
*
now*, I would personally be willing to cut ties with MRI, but that's a
really big "if".
I do agree with your point about 1.4. Unfortunately, it seems that we
have
some work to do before we can actually cut a release. Given the problems
with 1.3.5 and RubyGems, I think we should push as hard as we can to get
that work done sooner rather than later.
Daniel
On Wed, May 19, 2010 at 8:31 PM, Antoine Toulme<[email protected]
wrote:
We still have no 1.4 release. The two RCs look good on most OSes, but
Windows is not willing to cooperate.
I installed a Windows 7 VM and tried to run the specs. They mostly
failed
on
a Rake exception. I can investigate some more.
I am still not convinced depending on RJB is the future. I would rather
sever the links with it. My experience with Windows 7 showed me how
hard
it
was to install Buildr on it.
As a side note, I'm working on having rubinius support RJB, and Buildr,
for
fun and eventually profit. See my fork on github.
We also JRuby 1.5 now officially out. We should try to support it
correctly,
which means more work on our end.
All in all I think releasing 1.4 is now compromised, and we need to
address
stability issues related to RJB, as well as support JRuby 1.5 and in
general
become more OS independent to survive on the long run.
Thanks,
Antoine
