Charlie Nutter joins the Ruby Rogues to talk about the intricacies, power, and uses for JRuby.

Special Guest: Charlie Nutter.

 

Anyone else? Anyone else ever had chicken in waffles? Come on!

I can't say that I have actually.

It’s a really…Anyway, are we going to do a show today? [Laughter]

Yeah, let’s do the show.

Yeah.

We’re talking Yay Ruby today.

Yay Ruby, I like it.

Hey everybody and welcome to episode 124 of the JRuby JRogues podcast. This week on our panel, we have Katrina Owen.

Hello.

Josh Susser.

I'm null for something completely different.

David Brady.

I was hoping you were going to try to say JDavid JBrady.

[Laughs] I’m Charles Max Wood from DevChat.TV. Before I introduce our special guest, I want to just briefly make a quick announcement and that is this Friday is my Freedom Day. It’s the day that I got laid off three years ago and I am celebrating that. I'm celebrating my freedom by putting out a free video that kind of talks about the first year or so that I was freelance, how I found clients, how I got started, how I put my business together, all that kind of stuff. So, if you're interested in that, you can get it at GoingRogueVideo.com. Anyway, like I said, it’s free. So, just go and hopefully it helps some folks out who are interested in going freelance. Anyway, our special guest this week is Charlie Nutter.

Hello there, everybody.

Hi Charlie.

Charlie, you haven’t been on the show before. Do you want to introduce yourself really quickly?

In this community, I’m primarily known as one of the JRuby guys but I've been doing Java/JVM development stuff for probably 15 years. I've been working with Ruby and JRuby for almost ten years now, and just having a lot of fun trying to make Ruby work on the JVM.

Is that hard?

It’s not an easy project, no. I've always wondered if they will ever be actually done-done. And I'll find another bunch of things that going to take a little while to get working.

How’s refinements coming along?

[Chuckles] Well, after some intense deliberation…

Charlie, you're being baited.

I know. [Laughter]

Cool. We’ve been talking about doing this episode for a long time. I've finally been using JRuby on a project for a couple of months now. So, we felt like we have enough people on the panel to grill you about this. We’ll ask you useful questions.

Can I interrupt again? This is my dysfunctional disorganization speaking.

We have the most important announcement of the episode.

We neglected to announce our Unofficial Rogue. We have another person that’s signed up supporting the show. They donate $50 a month is what they do.

Wow!

And we think these people are awesome. And I get some Unofficial Rogue status and we mention them on the show a couple of weeks ago. Christian Schlensker donated to the show and so we’d just like to publicly thank him and all the other people who are supporting the show.

That’s awesome. Thank you.

Thank you, Christian. Yehey! [Clapped his hands]

Anyway, JRuby.

Yeah!

We actually didn’t start talking about this episode six months ago. We started the JVM six months ago and it’s just now warmed up. [Laughter]

Charlie, it’s okay to reach through Skype and slap him.

That was the one joke I had prepared for today.

[Laughs] You're saving that one up, I'm sure.

That’s right.

Yeah. We have been wanting to do this episode for a while, though.

Yes.

Well, it’s great to be here to talk about it.

Charlie, can you tell us how JRuby came to be, how did they get started?

The history of JRuby is interesting and not terribly complicated. The actual project started in 2001 or so. Neither Tom Enebo nor I, the current co-leads of the project were involved at the time. This guy in Germany, Jan Arne Peterson decided to port the Ruby parser over. I believe he was interested in possibly implementing the language, possibly implementing IDE tooling or editor stuff. But he got the basic parser working and with that groundwork laid, he proceeded on with a couple of other folks to actually start making the early versions of JRuby work. I think it was Ruby 1.6 timeframe, that’s what they were first targeting. Tom, I think, got involved 2002 or 2003, something like that. I got involved 2004 or 2005 and pretty much nobody that originally worked on the project is still involved these days.

So, how did you get involved?

Actually, this is one of my favorite stories. It’s also how I got into the Ruby community. As a Java architect guy at a government consulting firm, as enterprise-y as you could possibly get, a friend of mine recommended this language Ruby to me. It turned out that RubyConf 2004 was going to be just a few miles from the home office that I commuted to sometimes out in the Reston area in Virginia. So, I thought, “Okay. I will go out. While I was at the home office, I'll check out this Ruby thing.” I've never actually looked at the language but at the time, it was like a $65-conference. It was easy to get to. So, I thought I’d go and sit down there for a while. And while I was sitting there, I was struck by how every presentation I saw, I understood every piece of code without knowing anything about the language at the time. And I kept going from presentation after presentation. David Hansson was actually there presenting Rails for the first time. And that looked way better than anything I was doing in the Java world. And so I thought, “Okay. I'm a Java guy, a Java Enterprise guy. Maybe there’s some sort of JRuby out there that I might be able to use or play with so I can actually use this language in my daily work.” It turned out the project was out there. It also turned out that the current lead of the project was Tom Enebo. And I had worked with him about ten years before that at the University of Minnesota. So, we already knew each other. Dropped him a line, said I would like to get involved and that’s how it went from there.

I love the synchronicity of the event.

It’s just the most bizarre coincidence that both Tom and I ended up lining back up in this project and it led to where we are today.

That’s awesome.

That’s cool. How long have you been working on this? I'm trying to do the math here.

I started working on it a little bit in 2004, just kind of getting familiar with it. At university, I never studied compilers or languages or anything. I never thought I’d be interested in implementing them. So, there was a little bootstrapping time to get into it. I really started working on it in earnest kind of in late 2005, and then 2006 mid to late 2006 was when Tom and I actually were hired on by Sun Microsystems to work on it full time. And we’re both working on it full time at the same companies bouncing around a bit since 2006.

It’s hard to believe that that’s been seven years.

Yeah, seven years now. And amazingly, people seem to be still happy to pay us to work on this. I think it’s awesome for the community that we’ve been able to do this. It’s not like we’ve ever been in JRuby to make some crazy money off of it. We’ve always just kind of found this a labor of love and been lucky to find companies willing to sponsor us.

It’s very cool. Is it something that Red Hat seems to care about? Obviously, they’re paying you to do it.

Right, exactly. So Red Hat, they have a lot of folks within Red Hat that like Ruby. They have projects that use Ruby throughout the company. And whether to build products off of Ruby or to use it more efficiently internally, JRuby helps some of that future for what they want to do with the language in general. Specifically, they’ve been working on TorqueBox project for several years now. TorqueBox is basically a bunch of really nicely crafted Ruby APIs that wrap up all the different JBoss services. And since that’s a JVM project and it uses JRuby, we have been talking to them for a while about coming on board and helping to really support them.

Cool. That’s great. I mean, it sounds like a nice situation.

Do you have any idea how many people are using JRuby in production these days?

It’s the question we always get and it’s really, really hard to tell. The thing about open source projects is that if you're doing your job well, you never hear from anybody. [Chuckles]

Unless it’s busted. No one comes and says, “Hey, it’s working great and I never have any problems.” They only come to complain to you when something falls apart.

[Laughs] That’s not just programmers.

Yeah, exactly. So, finding the people that are actually running JRuby is a challenge. We do know that over the past two years or so, probably starting in late 2011, more and more, when we’d go to Ruby conferences, we would have dozens of people come up and say that they are running JRuby for something. It started to seem like there wasn’t a Ruby shop out there that doesn’t have something that is using JRuby or that has used JRuby at some point. It’s still really difficult to tell but we do know a number of big Ruby shops that have moved all of their stuff or at least part of their stuff over to JRuby. The activity on mailing lists and bug trackers and on other non-JRuby mailing lists seems to continue to go up. So, I think we’re trending in the right direction. But it’s really hard to get a pulse on that community.

Are there any JRuby specific conferences? I know there was one in DC two years ago but that’s the last thing I heard.

Yeah, we had our first specifically JRuby conference as kind of a tag-along/sidecar event for RubyConf 2009. We basically just tacked on another day. Sunday was JRuby Conf. It was a free event that time and we had probably 100 folks that stuck around after the conference to go to that. Since then, we've done one every year. We did 2010 in DC, 2011 -- I'm trying to think which sequence it was. No, 2010 was one we did in Ohio. It was tacked on to eRubyCon. eRubyCon essentially became JRuby Conf that year. 2011 was in DC. 2012 we did in Minneapolis and that was really awesome to have it at home here where Tom and I live. And then this year, we didn’t end up doing a US edition but we did have the second version of JRuby Conf EU that was part of the Eurucamp events in Berlin.

Sweet. If everything is turning in the right directions, these get a little bit larger every year? Is that right?

Yes. JRuby Conf 2012 was definitely the largest we’d had in the US. I think we had 200 or 250 people. It basically sold out the venue that we had set aside for it. We didn’t run it again this year mostly because we just didn’t have organizers. Other conferences took up a lot of time. But yeah, definitely seeing a trend where more or more people are interested in going to JRuby confs. So that’s one way that we've continued to be confident that we’re moving in the right direction.

I’d like to ask the question, what is it that gets people interested in JRuby? What is it that they are looking for and what problems are there that it’s solving for them?

I think the way I was going to ask this is like, what's the elevator pitch for JRuby?

Right.

If somebody hadn’t heard of it, why would they be interested in it?

There's actually a couple of elevator pitches depending on who we’re talking to. I'll get the Java community out of the way first. The elevator pitch for the Java community, since they already know about the Java libraries in the JVM is basically trying to sell Ruby. And that’s something where we actually could use more help. We’re so deep into the internals of JRuby, we’d love to have more Rubyists come along to Java events and show people what they're missing. The elevator pitch on the other side for Rubyists is usually one or two things. Either there's something about whatever Ruby implementation they're on currently, usually MRI, that’s not meeting their needs. Be it performance, garbage collector, threading, et cetera, all the things that you hear about JRuby. Or they have a specific need to use certain Java libraries, integrate with an existing Java infrastructure/enterprise or they have a customer client that refuses to run anything that doesn’t run on a JVM. Those are kind of the two main areas where people come to JRuby from the Ruby side of the world.

I have to say that the project I'm using it for now, one was a Java library that we had to use and the other was we’re running this thing on a fairly beefy server box that has a couple of dozens cores. And it’s amazing to be able to fully utilize all the cores because we have a very highly parallel problem we’re solving that threads nicely. It’s like, “Hey, all the cores! Yehey!” CHARLIE: Yeah. The concurrency thing has become a bigger and bigger deal over the past few years as machines are just doubling in cores like every couple of years now. I never expected to have four cores or eight hyper-threaded cores in my laptop and this is not even the newest machine. This is a couple of years old at this point. And then, you look at servers and you're talking 16, 32, 64-way machines. The idea that in order to fully utilize that, you’d have to have 16, 32, 64 separate processes and then possibly twice that for redundancy. It really just doesn’t scale to where we needed to.

That was my experience as well, came for iText which was a PDF manipulation library that just didn’t exist in Ruby. You come for the Java but you end up staying for the Ruby.

Yeah.

Or a lot of folks would basically come for one side of the company. They come for Java library and stay for what they get out of the JVM at that point.

So, we talked a little bit about some of the benefits of JRuby, with the garbage collection, the threading. In general, I hear a lot about speed. What are some of the drawbacks? Because I know for example on a project that Dave and I worked on, sometimes the JVM took a little bit of time to warm up. Are there other drawbacks to using JRuby?

The startup time issue is number one pain point. And we know it, we’ve known it for years. To be honest, there's only so much we can do above the JVM level. JRuby is kind of unique among the current production-ready, production-usable Ruby implementations and that probably 99% of JRuby’s code isn't made of code when you start it up. Auto-parsers are written in Java and that has to warm up. Interpreters are written in Java and that has to warm up. Various parts of the core are written in Java or Ruby and all that has to warm up. So, we’re essentially booting a VM on top of a VM and paying the startup cost for both of them at that point. So, that’s the biggest one. Hoping to work with the JVM guys to improve that in the future or find other tricks of our own. The other big one and it drops off really fast after this as far as pain points. The other big one is the lack of support directly for MRI’s C Extensions. We shipped C Extension support in some form in JRuby 1.6, kind of ran a few extensions, pretty much only support 1.8 mode. But it was kind of hacky, it really limits concurrency. It wasn’t very good performance calling across that boundary. So, most of the time, if people are going to make the migration to JRuby, they will end up having to find replacements for C Extensions rather than running them directly.

The other thing that I've run into in a couple of different ways is the POSIX Compliance and a couple of issues with that.

Right. We’ve done a lot of work to try and make JRuby as POSIX compliant and POSIX friendly as MRI. Obviously, with the JVM trying to isolate all of that, we've had to put in our own native bindings to certain POSIX functions and whatnot. It does still come up as a headache sometimes especially in the area of process management which we’re still working on. But in general, we feel like we can get there. It’s just a matter of time and priorities.

I think the one thing I ran into that made me a little sad was that I couldn’t trap SIGINT.

Ah, yeah. I think that one, you actually can trap. But the JVM really doesn’t want you to because it’s using it for other stuff.

Yeah. It’s like, “Damn you!”

Exactly.

The JVM is using Ctrl-C for itself?

Well, the JVM basically has its own SIGINT handler that does sort of a hard but somewhat clean shutdown of the JVM. And if you trap it yourself, then you can't do like a complete shutdown of the JVM when you want to. So, anybody who’s used to the JVM just going away when you hit Ctrl-C, all of a sudden you’ve got something else in the way. You can actually see this if you run IRB in JRuby. IRB does install SIGINT handler so that it can cancel out of the current code you're working on. But JVM users that expect a console JVM process to just end when you hit Ctrl-C, sometimes get surprised by that behavior.

I mean, is there a way that you can set up an atexit kind of trap or just a trap for SIGINT so that you can report something on the way out of the JRuby?

I think it does work. The trick would be that if you want it to continue to do the standard JVM hard exit, you’d want to call into like the java.lang.system.exit just to pass it on to the JVM and let it shut down the rest of the way at that point. But it is possible to actually hook it because I know IRB does it.

Okay. Maybe I just haven't found the right magic recipe for that. Anyway, moving on. [Inaudible] [Laughter]

We’ve talked a little bit about the popularity of JRuby within the Ruby community. I'm curious how popular it is among the JVM languages community. Is it one of the bigger ones? Is it middle?

Of the JVM languages that were not born on the JVM, it’s probably if not the most popular, probably very close to the most popular. The other one that would be popular as well would be Jython which hasn’t had as much work over the past few years. And I think it’s kind of slipped in popularity there. In comparison to the languages that were born on the JVM like Groovy, Clojure, Scala are the other three major ones, I think we’re still pretty far behind as far as adoption among JVM people, JVM users. But if you take our Ruby side, the Ruby users as part of the JRuby community, it’s likely that we’re probably still one of the more popular JVM languages. Again, it’s a really hard dynamic to figure out what's the size of our community when we've got it sort of bifurcated into two. They don’t really talk to each other. We don’t know on either side who’s using JRuby for what, but probably the most popular off platform JVM language.

Sweet. One of the things that you talked about was you said all the different pieces that are there in the JRuby system. And you said something about their being an interpreter written in Java. Can you talk a little about this, like the internal structure of JRuby because I think it’s not really clear to a lot of people how the Ruby code actually gets executed.

Right, that would be useful. Initially, JRuby was done basically as a port of MRI. The interpreter was literally a direct port of the Bison Grammar. The lexer was mostly a line by line port. And then, the interpreter was just an AST that we had an AST walking interpreter form. Those pieces are still mostly the same as they are in MRI; a lit bit of variation on how we construct the AST, a little bit of variation on how we actually do the interpreting. But then, we continued on from that point and added a compiler that can turn the AST into JVM byte code. We implemented all of the core classes on our own. So, the code that comes into JRuby will go through a couple of hops before it actually gets down to JVM byte code and then hopefully, that eventually gets JITted down to the native code so that we get the performance we need.

Wow! So, if I'm running a Ruby script, is that going to initially run -- I mean, it’s…the…[sighs] [Laughter]

This is the best question ever!

You should see what my hands are doing right now.

It’s funnier because Josh never does this. He’s really articulate.

I'm just like trying to figure out what's going on here because…

The answer is yes. [Laughter]

Great, thank you.

Almost all code that enters JRuby at first pretty much like any JVM byte code that enters the JVM, we will interpret it for a while. There's a cost to analyzing the AST, doing our own optimizations, trying to get into JVM byte code both in time and memory. And the vast majority of Ruby code that you hit will only get run once or twice, not a lot of code that gets hot. So, we wait until methods get called, I think the metric we’ve got right now is 50 times. And then, on a method by method basis, that gets compiled down to JVM byte code and the JVM takes it from there and optimizes it. So, it really is like a little VM on top of a larger VM.

So, there's like two levels of JITting going on?

Yeah, exactly. And we often deal with a lot of the same issues the JVM guys have in implementing our JIT layer.

Okay. That’s crazy. I'm impressed. [Chuckles]

CHARLIE: Thanks.

Thanks for keeping all that craziness to make it work well.

Yeah. I think we may be unique among the JVM languages in having that at all. There are some that can be either interpreted or compiled but none of them are mixed mode like the JVM is. And so, that’s been kind of an interesting challenge implementing a mixed mode VM on top of a mixed mode VM.

Okay. I think the thing that drove me a little insane there was thinking about the Java code that is the implementation of the Ruby interpreter that is interpreting the AST. And that code gets JITted and turned into native code. [Chuckles]

[Laughs] Yes. The interpreter will JIT itself and the AST will JIT and then we’ll do a compilation that turns that into byte code which will eventually JIT. And so, yeah, there's this code getting compiled in native all over the place.

I'll be right back. I need to get a bottle of scotch.

It will make this go a lot smoother.

Every time there's an update to MRI, you wind up getting a whole bunch more work to do, right?

Yeah, to some extent. Over the past couple of releases, it hasn’t been as bad. The 1.9 series, as it probably appeared from the outside, was a tremendous amount of changes and features. Not the least of which of course is the encoding support, massive change. It touched basically all of the internals of MRI. And we’re still working through compatibility issues in that area. 2.0 and 2.1 have been much more incremental, oddly enough, especially since refinements kind of became a sidecar experimental feature in 2.0. Most of the 2.0 stuff, we were able to implement in like a couple of weeks once it had been finalized. The 2.1 stuff again, is not huge amount of work. We’re actually hoping that with the next major release of JRuby, this will be that we finally catch up and we can just go and lock step with MRI as they come up with new features.

So, what's been the hardest feature to implement in JRuby?

As far as visible Ruby features, the encoding support is by far the most complicated thing, the most complicated single thing. Obviously, getting all of the core classes to work as they're supposed to, building array class from scratch and a hash class from scratch is a lot of work. But encoding has just touched so much of the internals of JRuby that required such a change in how JRuby itself was structured. That has to be the biggest one. That really forced us to do things like porting Oniguruma. We had to contribute it, basically port it over the entire regular expression engine that MRI started using because it was no way we’re going to support it, support the features otherwise. There's nothing that comes close to encodings.

There's a couple of different Ruby VM projects going on. Of course, there's MRI, there's Rubinius, JRuby. How much collaboration do you do with these other projects? And do you make much use of RubySpec, Rubinius developed libraries, any of that?

Right. We've always wanted to have more collaboration. I don’t know if this affects other communities the same way. But at some point, it always seems to kind of become an ‘us versus them’ even if we don’t intend for it. The community wants us to fight. They want it to be ‘us versus them’. We have people that file bugs and say, “Rubinius is faster at running this. What's wrong with you guys?”

Or, “MRI doesn’t do it this way. What's up? You guys suck.” And so, even though we try to collaborate and we try to work together, the forces that be just kind of push us apart. That said, we do talk a lot. Those of us that are kind of at the decision making levels of the different projects, we do talk about how we’re implementing certain features. We share war stories, we share implementation ideas. A lot of features that are in the Rubinius VM have come either from the way JRuby has done it or from things in the JVM. A lot of the internals of how we implement some core classes in JRuby have come from watching the Rubinius guys do it. You mentioned RubySpec. We do run RubySpec, so we have some contributions in there. Not as many lately, but we do contribute to it when we can. But we also run MRI test suite. And I am a MRI committer and I've made fixes and performance tweaks on MRI as well. There's collaboration. It’s not as much as we’d like but maybe it’s the best we can do right now.

It sounds like your heart is in the right place. It’s the best answer I could hear.

I really would like for us to be more of a common community because honestly, I don’t think that other than like VM level features. Rubinius and JRuby both have good concurrency. We both have good performance because we've got JITs. The overlaps end at that point. Rubinius and JRuby have completely different communities. JVM folks just want the JVM. People who want Java libraries are going to use JRuby. That’s kind of our distinguishing factor. People that want C Extensions or want more of a native experience as far as Ruby goes, Rubinius might be the better one for them. And those are things that are never really going to change a whole lot. So, we do still all have our own sectors of the community that we can survive in.

Okay, that’s really cool.

What is your process for adding a new feature into JRuby? You just look at MRI and add it to the list or do you discuss how? And once you decide to add it, then what do you do?

If it’s a feature that’s officially added to MRI, generally we don’t have a choice about whether we’re going to add it to JRuby or not. It’s more of a matter of timing and when we’re going to get there. We have, within our team, everybody that kind of has their own areas that they work on. Tom generally works on -- he’s pretty much the main person that works on parser. He does a lot of work on the interpreter and then kind of shares the load on doing core class stuff. I work on compiler, on optimization. I do a little bit of work on collaborating on new features like refinements, like some of the freezing of strings and stuff that’s coming up in 2.1, trying to prepare us for the future of stuff. We have Wayne Meissner who does the native layer and FFI stuff. We’ve had MenTaLguY help out on concurrency stuff in the past. So, depending on what the feature is, we usually have specific people that we can kind of hand it off to and then we’ll share certain aspects of it. But everybody’s got their own role to play on the project.

I'm a little curious too about the different moving around that the team has done. I know you were at Sun and you were also at Engine Yard, I believe. Then you went back to Oracle and then now, you’re Red Hat. How has that affected the project?

The sequence is actually that we started out 2006 working full time at Sun. And that was when they were really first getting into the idea of JVM languages being a cool thing. So, we were there for a couple of years. And then towards the end of that, the whole Oracle thing happened, kind of got a weird vibe from it. Nobody could tell us yea or nay whether we’re actually going to have a job in six months. And Engine Yard was interested in bringing JRuby in-house, getting it available in their Cloud. So, we migrated to Engine Yard at that point and that was Tom, Nick Sieger, and I all migrated at the same time. Worked for a couple of years there, helped them get JRuby up and going in the Cloud, got it out as a product offering. And then, once we’d finished that, it kind of seemed like maybe the reason we went to Engine Yard was mostly done. They had it up and going, they had some customers using it. And Red Hat was at the time, making a big push on their TorqueBox product, wanted to try and get it out for more users, wanted to actually do some formal releases of it, get some real traction behind it. And so, we knew the guys at TorqueBox, we knew the work they were doing, and we knew that they had a growing JVM language sub-group within the JBoss side of the organization and it seemed like a good time to make that move. And that’s where we’ve been for a little over a year now. We can't be understated how much we appreciate every one of the companies in this line that’s been supporting JRuby because they're not just supporting it for their own interests. They’ve been supporting it because it’s good for the community to have JRuby around. It’s good for Ruby’s future and Ruby’s health to have alternative VMs and have a way on to these other platforms. So, we’re really thrilled for everybody that we’ve been able to work with.

I think it’s awesome that the Ruby community does this. It’s not the just the Ruby community, it’s all sorts of communities supporting this. But if you look at some of the other successful languages, Java had corporate sponsorship from Sun, PHP was supported by Yahoo, Python supported by Google. There hasn’t really been one big supporter for Ruby throughout its history. It’s been a lot of little players or relatively smaller players. But I think it’s just great that there's always somebody who steps up.

Yeah, exactly. It plays into a theme that Reginald Braithwaite was talking about just this past weekend at Baruco. He did a really excellent talk about how the real benefit, the real advantage that the Ruby community has in comparison to other communities is how social the community has been, how this community has basically invented social coding on the back of GitHub, still by far the biggest GitHub users. We have conferences all over the place. We’ve split our community up and had lots of different ways of communicating and getting together. We do all sorts of nonconference events, all sorts of online hangouts, all sorts of online groups. We’re not a community that requires the cathedral to be pushing everything forward and one entity to push us forward. It’s made up of all these little communities, these little bazaars. And then the little stance within the bazaar that are all contributing to the same whole. And it’s like no other development community that I've been involved in, embracing really the open source and social community thing more than anybody else.

Okay. As someone who writes open source gems, how do I make sure that my gems work for all the implementations of Ruby or at least the most common ones?

The first and most obvious thing is the amazing contribution in the community the TravisCI has been. It’s become like GitHub where I can't imagine what life before Travis actually was like. It’s really trivial to flip JRuby on and flip the other implementations on. It’s even easy to go to somebody else’s project and send them a pull request to just add JRuby to the list of projects they're running in Travis. That’s the easiest way. Get it going on tests, see what the problems are. If there are things to fix on your end, on your library, you go ahead and fix those obviously. If there's stuff that looks like it might be a bug in JRuby, we’re happy to sit down and try to figure out what those things are. This is really the number one thing that Ruby community folks, Ruby users, the thing that JRuby users can do to help JRuby or help the other implementations is get all the libraries tested, get that groundwork solid across everybody, all the implementations. Then, we can build from there. If all the libraries work and all the code that people expect to build their apps off of works, it’s going to be a larger community for everybody.

So, it’s really intimidating when I try to run it against, for example, JRuby. And then I get errors that I don’t understand and I'm not sure if -- I don’t know where to go to ask questions. Mostly, I'm pretty sure that it’s a stupid question. I'm going to look like an idiot if I go ask this thing. I'm wondering, how do I mitigate that? First of all, how do I go and how can I figure out if there's some homework I can do first before I ask my question?

The way that, at least, I've approached managing the JRuby community and folks that are new to it or coming into it, I almost always assume that there's probably something we’re doing wrong in JRuby. So, I can't emphasize enough that if there's anything that looks like it shouldn’t be that way or if there's possibly any potential that it might be a JRuby thing, totally, just come to us. We have mailing lists which I monitor not as well as I could. There's a bunch of other folks that pay a lot of attention to the mailing lists. But the IRC channel, JRuby on Freenode, you can come in there, ask a quick question, throw a gist up. We’ll take a look at it. If it is what you call a dumb question, we’re really happy that we’re able to keep [inaudible] spinning your wheels on it. Give me the quick answer, point you to something in the Wiki, whatever, just to make sure that you're able to move forward and get on to something meaningful. If it’s an actual problem, even if it’s not something JRuby specific, we usually are also helping -- not usually, we’re always happy to help sit down and figure out what the problem is. We’ve had some real unusual folks come into the channel that weren’t actually very skilled at Ruby, they were new to the language, didn’t really understand how certain aspects work. And we’re still happy to try and sit down to figure out what's going on. We really just want to kind of make the community feel very much at home with Ruby as well as JRuby.

That’s cool because that’s often the biggest hurdle is just kind of figuring out how to get started asking the right questions.

Yeah, exactly. Any problem that somebody has with JRuby, no matter how small, is an opportunity to improve JRuby either by fixing a bug which is obvious that we want to do that or by making it easier to do it the right way. If it’s a problem getting JRuby up and running or deploying it or finding the right libraries, the right gems, it’s not your fault that something might look wrong or that it might be difficult to get up and going. It’s generally our fault or there's something that we could be doing better to reach community members like you that we’re more than happy to try and make happen.

So, do I need to run it against a lot of different versions of JRuby?

I’d say pretty much just whatever the current JRuby release is. Our VM style will just be whatever is installed for “JRuby”. If you want to move to the next step and help the JRuby development process running against JRuby head as well, will help keep us honest and we’d periodically paying the Travis guys to update that to a more recent version of JRuby Master. But the most recent JRuby version, we always recommend people to run on the latest version and that’s what we really expect people to test against.

Cool. Thanks.

I have a question or two about the Java side integration because that’s one of the big selling points of JRuby is that you get the benefit of this big Java ecosystem and that’s one of the reasons we chose it. Actually, the main reason we chose it. There's definitely a little impedance mismatching going on there. Java is a statically-typed language. It has a different outlook on a lot of things and I've been noticing that the seams between the Ruby side and the Java side can sometimes be a little rough. Like one thing in particular that I've run into is dealing with Java class constructors. Oftentimes, they’ll take primitive data types or even just any method that takes primitive data type has issues with this. But if something wants a byte array, then that took me a little bit of head tilting and squinting to figure out what's a good way to interact with these kinds of things. And then, there are things like database drivers and that whole side of things. Oftentimes, it’s a lot of the edges, the system look really different than what I'm used to in just a pure Ruby kind of world.

Right. This has really been one of the bigger challenges for JRuby, not just for Rubyists who want to use JVM libraries but for JVM or Java folks who want to use a different language. All the languages that were born on the JVM obviously were born to integrate with Java at some level. And so, it can often be a little easier for them, a little more seamless whereas we have to marry Ruby which is dynamically typed, it has its own type system, its own notion of what a string, an array and a hash is, with Java which has static types. It has a completely different representation of a string. It has its own set of collections. Over the years, we’ve added more and more little shortcuts, automatic conversions, utility methods. We try to document as much of the stuff along the way but it’s a big set of APIs and a big challenge. In general though, we do want to know where those seams are and what the most difficult aspects of integrating with JRuby with the Java library is. To be honest, a lot of times, it’s the Java libraries are not really designed well in the first place. They are designed specifically to integrate with only Java and even Scala or Groovy would have trouble with them. Or they don’t even take into consideration that other languages might be around that might have their own type systems or their own representations or collections and so on.

That was definitely my impression with this one library that I'm working with. It’s not the most object-oriented thing in the world. There's not a lot of opportunity to massage it around and put in a different shape.

The best experience that JRuby users have had with Java libraries is usually when somebody with a couple bottles of scotch and a little courage goes in and actually builds a very nice Ruby wrapper around whatever that library is, works through a lot of those low level issues and comes up with something that is a nice API for Rubyists. An obvious example is what the TorqueBox guys are doing. The service is there providing our very Java Enterprise-y like under the covers. That means that they're very solid, they perform well, they have a lot of functionality but if you were to use those APIs directly, you’d be completely lost. What they’ve done is put a very nice Ruby face on top of all those to make them look as good as any queuing service or data cache or anything else. That’s usually the recommendation we have for people. If you're going to use a specific Java library, take a first pass and wrap it with something that feels a little bit more like Ruby. Treat it sort of like you're integrating with a foreign library or a C library. You don’t necessarily want to use that API as your Ruby API because it’s just not going to fit into the system the way you’d like.

Actually, I had considered doing that before. The most useful thing I've run into -- well, one of the first useful things was a similar situation where I was up against a seam. And what it was is it was a seam into -- I wanted to do some graphing and plotting and the support for that in Ruby is quite poor. I mean, graphics is just kind of an orphan child. I was casting about for how am I going to do this. Am I going to use Rmagic and draw an image? And now I realized I've got all of the Swing libraries and the Canvas 2D and all of the stuff. I can even open a window and draw the silly thing. And that was one of the first things that I got into with JRuby and I was able to produce some really nice graphs and charts. The interface wasn’t quite perfect but it was actually close enough to [inaudible]. And so, sometimes those seams, their [inaudible] is painful to cross them but you have to because the thing on the other side doesn’t exist in the Ruby ecosystem. Does that make sense?

Right. You're almost saying that the seam between Ruby and Java or in using of Java library from Ruby is really just that it’s a Java library.

Yeah.

It’s designed for a completely different sort of developer, developer that has a big IDE that’s going to complete all the stuff for him that is potentially planning for the 99% case and not really considering that maybe things are going to be a lot simpler at the same time. It really is kind of just the way that Java libraries are written. They're low level system libraries that you want to put a nice face on.

Yeah.

So, what's next for JRuby? Where are you guys headed now?

We’ve been desperately trying to get the JRuby 1.7.5 Release out. We did our 1.7.4 last spring, I think it was actually spring still. And then, 1.7.5 just kind of snowballed. We did a big rewrite of a bunch of encoding stuff. There's a bunch of optimization work. This kind of gathered more and more work, more and more improvements over the summer. Then we started having people test it out and of course, nobody tested it out until we say, “Hey, we’re about to release it.” And so, that has pushed things back a couple of weeks trying to get all the user cases that have come up resolved. After that, we’re planning on branching off for the next major version of JRuby which at the moment, the working version is JRuby 9000. We kind of want to make a break from the old code base, rip out all of the Ruby 1.8 and 1.9 stuff, go straight to 2.1, build a new compiler, get a runtime for it, kind of make JRuby what we’ve always wanted along the way now that we’re getting to a point where functionality-wise, we’ve caught up.

How soon is refinement support coming?

[Laughs] I actually want to address this because it came to such a contentious thing during Ruby Conf last year. They’ve even considered putting this feature in, this horrible thing that nobody likes it. And then other people would say, “No, it’s amazing. It’s a wonderful feature. I want it because it lets me do all these crazy DSL stuff I couldn’t before.” Ultimately, the discussions around refinements showed to me that the existing process actually can work. I put up a blog post, I communicated on the refinements issue on a daily basis. And the end result was that refinements were marked as experimental in 2.0 so we could take some more time to look at them. Ultimately, Matz and other folks in Ruby core agreed that the feature set as defined was too crazy, too much magic, too difficult for VMs to implement, for VMs to make perform at least a decent level. What we’re going to have as refinements in 2.1 is a paired down version that I think still provides the bulk of the functionality people wanted out of the feature without most of the pain that I was concerned about originally. The refinements, even though it seemed like such a cluster when it first came along, it was kind of a success story for how Ruby core has been evolving the process and trying to communicate more, trying to work with folks in the community more closely. We did manage to fix something that might have been a terribly broken feature long before it ever got into release.

And definitely kudos to you, Charlie, for your role in that. I think that we need a lot of people, I guess you’d call it [inaudible] off about self that they had strong opinions about and not much grounding to speak from. You sat down and you did a lot of hard work to come up with test implementations and to actually look at the reality of the situation with a pretty critical eye. And I

think that what you did there really had a major effect on the outcome.

I'm glad I was able to do it. The thing is with any process, even if you think it’s a broken one, just chucking it and completely walking away is just going to let things continue on that direction. I've never been thoroughly satisfied with the way that Ruby core works but they’ve improved things over the years. They do listen and more and more, they listen to folks that aren't Ruby core, the folks that aren't part of the Japanese Ruby community. It’s really difficult for me when people say that the existing system is so broken, we can just throw it out completely even though it’s brought us to the Ruby we have today. I think we need to work within the community to figure out ways to evolve the process and improve communication. But I think over the past year or so, we’ve managed to prove that the current process, even if it is a little bit broken in places, can be made to work.

Alright. Well, it sounds like we’re winding down. Should we get into the picks? Everyone said their piece? Before we do the picks, I just want to thank you again, Charlie, for all the work that you’ve put in to JRuby. I mean, it really does contribute to the community and gives us some other options for things that we need to get done to solve the problems for our customers, clients, or employers.

Having a lot of fun with it, so I'm glad people are getting use out of it.

Cool. Hey Charlie, any appearances or speaking gigs coming up soon?

I was just at Baruco. Hopefully, folks were able to get out for that and will be able to see the presentation that I did there. I was pretty happy with it talking about The Future of JRuby in a little bit more detail than I was able to do today. Tom and I will be speaking at Ruby Conf this year. Our talk on The Future of JRuby was accepted and we’ll probably cover a lot of the same things. Other than that, those are the two Ruby gigs that I've got coming up or that I've got in the near time span. I will be at JavaOne next week. So, it will be around the same time as GoGaRuCo stuff but they're for a different event. And I'm going to be doing this YOW set of conferences in Australia in early December. Other than that, 2014 is still kind of an open slate.

Cool. Are we going to see a JRuby conf next year?

We surely would like to do it. We’re starting to wonder if maybe our idea of doing a separate JRuby conf, even though it seemed like it was pretty successful, doesn’t really fame to that social nature of Ruby in having lots of little conferences. So, it’s possible we may start to talk to existing conference organizers about having sidecar events, JRuby tracks, things like that because it’s really the folks that are existing Rubyists may be not using JRuby that we want to talk to the most.

I know somebody you could talk to.

Yeah. [Laughter]

Yeah. I'll be at RubyConf as well. I'm going to be speaking. So, I will look for you.

Excellent. We’ll be hanging out for a while.

Awesome. Let’s go ahead and do the picks. Katrina, do you want to start us off?

Sure. That’s going to be fast. I have nothing.

David, what are your picks?

Two quick development gems that have made my life a living hell and then made things much, much better. They say sometimes the shortest way through a problem is straight down the middle and just to fix it. And we have been having time zone related issues. I believe it was the great Josh Susser who once said, “If you don’t hate time zones, you're not a real programmer.”

And that’s absolutely true. Chuck, you and I can tell a funny story about time zones but we’ll save that for later. But yeah, tests were failing. You’d go parse a time and at 9 o’clock at night, the test would fail and it was because the current time zone had changed relative to GMT and whatnot. Alindeman on GitHub has a gem out called zonebie. And zonebie will change the time zone of your Rails system. Or if you're not building on Rails, you plug it into your test suite. I think it is Rails specific, sorry. But it changes the time zone that Ruby thinks it’s in every time you run your test suite to a random time zone. And this is beautiful because your time zone bugs never appear during the day, at least if you're in the Western hemisphere. And with zonebie, all of a sudden, your specs are running in Istanbul or Kazakhstan or Singapore. And all of these time zone bugs that only appear late at night, now are suddenly appearing in the middle of the day. We installed this and we suddenly had 50% just complete, all the test suite which is fail half the time randomly. You can set a flag to say, “You know what? Lock me to Singapore because that’s where this bug is appearing.” And then you can go track down all of your time zone bugs and change from time.parse to time.zone.parse and stop using time now, always use time current. Never use date today, always use date current, that sort of thing. So, you always lock in to the current time zone. So, zonebie is my first pick. My second one is rails_best_practices which is another gem that will do code quality metrics. But it will also do security analysis. It will analyze your DB schema for migrations, for indexes and that sort of thing. And if you're already using the metric_fu gem, you're already using rails_best_practices. But if you're not, grab it and give it a shot. Actually, if you're not using metric_fu, you should just use metric_fu. But if you're not and you just want to see the Rails side of the things, you can grab the rails_best_practices gem and run that and it’s awesome. And those are my picks.

Awesome. Josh, what are your picks?

I saw that one coming. [Chuckles]

Let’s see. I have one programming-related pick this week and that is the Dash Documentation Viewer. I don’t think anyone has picked this yet unless they did it last week when I wasn’t around. But this is nice, it’s a Mac app. You can get it from the Mac Apps Store, it’s called Dash. And it’s from a company called Kapeli, I believe is how it’s pronounced. And it’s just a really nice little Mac app that you can download documentation sets for Ruby, Rails, HTML, CSS and a whole bunch of other things that I haven't even gotten into yet. And it’s nice. It’s like a one-stop way to get all of those documentations on your local machine. When I was flying a couple of weeks ago, I'm trying to do some coding on the plane and all of my documentation is web-based and I can't find any of the docs for anything that I'm working on. So, it’s nice to just have them all downloaded and be in a form that works really well for searching. So, definitely liking that - Dash Documentation Viewer. And then I have a sci-fi pick. I've been doing a lot of those lately but I guess I've been doing a lot of reading lately. I've been rereading a lot of my old favorites. And right now, I'm rereading Peter F.

Hamilton’s Night’s Dawn Trilogy. This series is crazy. It was published in the UK as a trilogy but because we, Americans, can't deal with apparently big books, they broke each of the books in the trilogy into two different parts. [Chuckles] So, it’s a six-volume trilogy. Anyway, the first one in it is called The Reality Dysfunction.

Oh, yeah. Is this The Neutronium Alchemist series?

Yeah, The Reality Dysfunction, The Netronium Alchemist, and The Naked God. This is just like the most epic galaxy spanning space opera that really works that I've read in the modern science fiction age. It’s such a big scale. And the cast of characters, he has one of those dramatis personae sections in the books and you really need it. You just really can't tell the players without the score card. It’s such a rich and complex galactic milieu that is like even rereading it, I always see stuff that I didn’t notice before. And it’s a frightfully believable future in many ways. Anyway, that’s what I got this week. Have fun.

Awesome. I've got a couple of picks here. One is a product that I've been using for a while. I was using Pivotal Tracker for a long time. Anyway, for various reasons, I decided I don’t want to pay for it anymore. But I tried out Planscope.io which is done by Brennan Dunn and I'm really liking it. It has an estimation feature in it and it has the actual project in it. And it’s worked out pretty nicely for a few projects that I've run on it. So, I'm really enjoying that. Another pick that I have. This morning, I actually got up and went to the gym. And so, I'm just going to pick that. I know I've picked it in the past. But you know, just get up and move for half hour or an hour every day. It makes a huge difference and I feel a ton better. I feel a little bit worse too because I'm a little bit sore but I feel great. Finally, the last pick I have and this is so -- most of you know that I'm LDS or Mormon. And I drove down to the local temple which is, it’s not like the church or synagogue, it’s where we go for higher worship, I guess you could say. And I just sat in the parking lot and kind of meditated. I know some people aren't religious and some people are religious. But whatever it is that you do to go and kind of find a peaceful space for your thoughts and to talk to God if you believe in Him and just to have that time with your thoughts if you don’t, it really makes a big difference for me. And so, I'm going to kind of pick finding that quiet space and exploring your thoughts and where you're at and who you are. And that’s it. Charlie, what are your picks?

I got a couple of things and I’d go through them quickly. I actually got a little distracted playing with Dash just now because it’s very nice.

I was looking for a JRuby module to download just now and I couldn’t find one.

Yeah, I know. I didn’t see one. We’ll see if we can get something published for that but [inaudible]. The first one, I had the pleasure of hanging out with Sandi Metz again last week at Baruco. If you haven't checked out her book, Practical Object-Oriented Design in Ruby, absolutely do it. It sounds like the typical sort of dry design pattern kind of book but it’s so not. It really makes you excited about writing object-oriented programs the right way and the benefits you get from it. So, that’s the first pick. It’s probably come up before but I wanted to make sure people know about it.

Nobody has picked that book on this show.

You can even pick up Sandi’s talks from other conferences. The first time I saw her was actually at GoGaRuCo last year and I was very impressed. It was really entertaining to watch her lay it on the line there.

We should get her on the show to talk about that book.

Absolutely.

Actually, we should get her on the show to talk about anything. [Laughter]

Yes.

Let’s have her back soon. That would be great.

Yes, for sure. The second one is going to expose my rank newbieishness at Vim and doing C development. But since I started working on MRI and became an MRI committer, I have rediscovered Ctags. If you haven't used Ctags before to actually do some migrating or navigating around a large C codebase, you're doing it the hard way for sure. I had used it very briefly at university a long time ago and rediscovered it. If you ever need to work at a big C codebase, make sure that you're using that. The last thing I'll pick today is related to concurrency. Since concurrency has become such a big deal for Ruby especially JRuby, Rubinius, and whatnot, there are a couple of libraries. The first one would be the thread_safe gem. It’s a gem that I started up just to basically give people what they kept asking for, a thread safe array and a thread safe hash implementation. It’s a gem you can install on any implementation, gives you a ThreadSafe::Array or ThreadSafe::Hash that you can new up, use it like a regular array or hash and not have to worry about concurrency issues with it. And ideally, it’s going to be the fastest possible concurrent array or hash on a given platform. The other one is the atomic gem which if you're ever doing or= or += and you want those operations to be safe across multiple threads, you can use the atomic gem to make sure that only one thread is going to make that modification at a time and not going to step on each other. I have one last quick one. Anybody who’s starting to get in concurrency and using JRuby on the JVM, Brian Goetz’s book on Java Concurrency in Practice shows you a lot of the important libraries you need you know, talks to you about how the JVM’s memory model works, really teaches you what concurrency looks like running on top of the JVM, the pitfalls you're going to run into and the right tools to make it work. And all that stuff applies very well to JRuby too.

Can I throw in a bonus pick?

Yes.

It’s very Charlie-serving. One of the things that’s held me back from getting involved with JRuby sometimes is I keep wondering, “Gosh, how do you get down to the JIT level? How do you get down to the low level of manipulating something?” And I just started wondering as we were sitting here chatting, “How do you get involved with JRuby?” And the answer is you go to JRuby.org/contribute and they’ve got a freaking presentation on how to get your code bearings on the codebase. They’ve got all kinds of stuff you can contribute to. And so, if you're afraid of the JRuby source code [inaudible], they are actually open source and you can get involved with them.

Awesome. That’s great recommendation. And if there's anything that looks like we need more of like how do you approach a bug, or how do I find out what's going on in string, we’re totally willing to write more resources and put them up there for people.

You need more Smalltalk in it, right Josh?

Yeah, that would be great. [Chuckles]

Charlie, where's a good place to go to find low-hanging fruit like the ‘please jump in’ tag kind of stuff. Is there anything in JRuby that you guys are just [inaudible] have somebody jumped in?

It’s tough to maintain those list because if it’s a low enough hanging fruit, we’ll probably just fix it. But we do have in our bug trackers, we try to mark some intro bugs or help wanted bugs. Like what I'm saying earlier, probably the easiest way to get involved in just a general helpiness towards JRuby is look through the gems, the libraries that you use on a daily basis. Figure out which ones aren't testing JRuby in Travis and make it happen.

You’ll fix them. Cool. Awesome, thanks.

Alright. Before we wrap up, I want to mention that we are going to be reading Confident Ruby by Avdi Grimm and you get 20% off the book by using the code ROGUESCLUB, all one word, all uppercase. And that works on any of the editions. The episode will be recorded on October 16th and it will probably come out about a week after that. So, keep an eye out for that. Thanks for coming, Charlie. Really appreciate you taking the time.

Yeah, it was great coming on the show. Thanks a lot guys.

I guess we’re done. We’ll catch you all next week.