On RJB, by the way, the Rubinius guys looked at the code with me and they saw a few deprecated/bad practice/invalid places in the code.
I'm not sure if that would help at all having that code behave but it's worth trying. On Wed, May 19, 2010 at 21:28, Antoine Toulme <[email protected]>wrote: > You also have to consider that reusing the JVM all the time for compilation > and testing has nasty side effects. I can see jruby doing weird things for > example, when I push it to do a little too much. At least, if you spawn a > new VM every time, you stay on the safe side. And that gives you the > possibility to run different VMs for different compilation tasks (that's the > case for my project where we fire up JDK5 for Hibernate, but compile against > JDK6 for others). > > I also would target a solution that works across Ruby distributions, > without too much C code involved. > > > On Wed, May 19, 2010 at 20:00, Daniel Spiewak <[email protected]> wrote: > >> It would be interesting to see what kind of a performance impact shelling >> out would have, but I doubt that's even a functional option. Consider all >> the code we have which is dependent on AntWrap. What about our test >> filtering mechanism? To say nothing of potential third-party extensions >> which may use the Java integration (we've been pushing it as a feature, so >> I >> would expect more than a few of them). >> >> One thing we could try is to build a bridge layer based on sockets rather >> than raw JNI calls. We could spin up our JVM in a separate process >> (perhaps >> by shelling out) concurrent to our own startup. Calls into Java would >> still >> use the same API as at present and would still be synchronous, but there >> would be no direct contact between the two environments. It would still >> be >> a non-trivial effort to implement, but it would likely be less fragile >> than >> the current JNI-based RJB solution. >> >> Daniel >> >> On Wed, May 19, 2010 at 9:54 PM, Antoine Toulme <[email protected] >> >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 <[email protected]> >> 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 < >> [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 >> > > > >> > > >> > >> > >
