buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Van Eeckhoudt <pepijn.vaneeckho...@luciad.com>
Subject Re: 1.4, Windows 7, and a few news
Date Thu, 20 May 2010 13:41:48 GMT
I've only used buildr on JRuby myself so sorry if this comes across as 
ignorant. What kind of issues are you guys getting with RJB? I glanced 
through the code quickly and it seems to basically consist of the 
necessary JNI calls to call into the JVM from ruby. I don't think the 
JVM gives you any alternatives to this, so I would expect any other 
approach to have the same set of limitations as RJB.
JNA is a great library, but it basically gives you FFI functionality to 
call native code from the Java side. It does not provide any additional 
functionality for the case where you want to call into the JVM.

Pepijn

On 20/5/2010 15:31, Adam Young wrote:
> I would recommend looking at JNA for a Native interface to Java.  Much
> nicer and cleaner than JNI, and works faster. I made a quick spike into
> using it to have Java Call into librpm. I realize you are going from
> Ruby to Java, but if you are considereing JNI, then JNA can probably help.
>
> On 05/19/2010 10:54 PM, Antoine Toulme wrote:
>> I don't want to move away from MRI, but I think we need to have a way to
>> interact with the JVM without RJB.
>>
>> Either with JRuby, using the VM directly, or by calling javac over the
>> command line, like Maven2 does.
>>
>> I'm willing to do some testing to see if that makes us very slow.
>> I happen to have a project on github (under the user intalio, named
>> cloud-orbit), which builds with buildr and contains more than 200
>> projects,
>> most of them being very popular. I can use it as a benchmark easily.
>>
>> On Wed, May 19, 2010 at 18:47, Daniel Spiewak<djspiewak@gmail.com> wrote:
>>
>>> 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<antoine@lunar-ocean.com
>>>> 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
>>>>
>


-- 
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com

LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 11
3001 Leuven | Belgium | www.luciad.com


Mime
View raw message