 Okay, I think we can probably get started here. It's been an interesting day in the languages track. I saw a little Pearl 6 stuff. Some of it was interesting, some of it was a little scary. But we're going to talk a little bit different now. I am Charles Nutter. I am one of the two core, or the two lead developers on the JRuby project. And I'm going to talk to you a little bit about JRuby today and also try and give you a little perspective on why we feel like JRuby is a great open source success story and how some of you may be able to help us in the future. So I'm going to go through a quick Ruby intro. How many folks here know Ruby? Okay, probably half, a little bit more than that. So I'm going to run through it fast just to make sure that everybody is on the same page at least. Then I will do a little bit of information on the JRuby background, where it came from. Talk about the internal design of it, since that's really my area of expertise. Go through a few use cases where people are using JRuby and then have plenty of time left over for questions. So first off, who am I? Charles Nutter. You can call me Charlie. I've been working at Sun for about a year now, but I've been doing Java development for over a decade. I've been working full-time on JRuby these days and also trying to take what we've learned working on JRuby and expand that to other languages and improved language support on the JVM in general. I've done a lot of other crap in the past. Most of it I don't do anymore. So what is Ruby? Ruby is a dynamic type language like Perl or Python. It's pure object-oriented, so designed from the beginning to be object-oriented, and it shows it feels a lot more OO than a lot of other dynamic or scripting languages that are available right now. The standard implementation is interpreted. It's open source, and it's written in C, and it's reasonably readable code. But there are some downsides to that implementation written in C. It's green-threaded, like a lot of interpreters are, so it doesn't take advantage of multiple cores. It doesn't parallelize. It also doesn't have a greatest unicode support in the production version. There's a development release, Ruby 1.9, which is starting to gain a little bit of a traction. That helps with the unicode problem, but it doesn't really solve it completely yet. There's also far fewer libraries for Ruby than there are for Java or for other languages that have had more users over the years. And by most accounts, Ruby is slow. And, of course, performance doesn't really matter until it does. And Ruby tends to run into some particularly bad cases where it's one of the slower languages that are available. It's older than a lot of people think. Created in 1993, at least the idea came up in 1993, so it's been around for quite a while. Mott's our benevolent dictator in the Ruby community. He wanted a language that was more powerful than Perl and more object-oriented than Python. And, of course, he was referring to Perl 4 or 5 at the time, but I think he's done a pretty good job creating a great language. He's created everything he does for it. Pretty active community, and there's a lot of different versions in development. So a quick tour here. Say it's pure object-oriented, so basically everything's an object, even numbers. This shouldn't be any surprised at most of you that have used any other dynamic languages. All objects have a class, so even a number, you can get the class of it and it's a fixed num. It's single inheritance language. It's rooted at objects similar to Java. And object is the base. So a quick tour of the literals. One of the big things that languages like Ruby, and especially Ruby provide, is a number of different literal syntaxes that make it easier to express different types of data in the code. Some of the more important ones be literal regular expression syntax, literal hash syntax. Ideas that are considered for adding into future versions of, for example, Java, to try and make those easier. A couple obvious features you start to see. First day working on Ruby. The fact that you can do string interpolation makes it easier to build strings out of dynamic content. You can also override a bunch of operators. And the syntax is essentially the same as defining any other method. There's no special tricks required. It also supports quickly defining attributes. So if you've used other languages to define get and set for particular attributes in a given type, Ruby makes it one liner so that you don't have to do all that. And of course it's dynamic typed, or duck typing, as some people have started to call it lately. If it waddles like a duck and it quacks like a duck, it must be a duck. So in this example, we're calling the make it waddle method. And all that's required is that the past in object can waddle. Okay, Octopus doesn't. This would lead to a runtime error. But they rarely happen. And generally if you're testing your code well, you don't see them. So here's a simple class in Ruby. Initialize is the constructor. Here it prints out a message from the instance variable at message. Ruby tends to follow some of Pearl's design using leading sigils for particular types of variables. And then at the bottom we construct an object just by calling the new method on the type. Ruby also supports closures, which seems to be the popular feature to add to languages these days. But from the beginning, Ruby supported closures because it was based largely on small talks design, which has head closures. So here's two formats for doing closures. The only real difference between them is precedence. And for the most part, people use the do end version for multi-line closures. At the bottom we can see that there are two different examples of methods that accept a block. This yield is a keyword that allows you to call the past in block implicitly. And the second example allows you to explicitly capture the block in an object and call it directly. So modules are kind of Ruby's way of getting around the fact that it's a single inheritance language. Here you can see that we include an innumerable module. Ruby provides a whole bunch of features that you might want for an innumerable collection, being able to select certain elements out of it, being able to sort it, to find the max, find the min, and doing all the other operations. So all that's required for you to turn a type into an innumerable is to include that module, mix it in, and define one method each. And that gives you all of those other features, just based in terms of each. So you can see at the bottom, we're able to do our selects and our sorts. So what's JRuby? Everybody that knows Ruby already is now sighing and saying, okay, good, we can move on to the interesting part here. What is JRuby? JRuby is a Ruby implementation that runs on the JVM, essentially. We've worked very hard to make it compatible with Ruby 1.8, which is the current standard version. And largely, we want people to just think of JRuby as another Ruby implementation. So many people that consider JRuby sometimes dismiss it because they say I don't really like Java, I don't want to work with Java. And so I try and stress this point pretty heavily. JRuby is just Ruby. You can just write normal Ruby code and never really realize that you're running it on top of the JVM. We've had lots of contributors and I'll get into some of these guys a little bit more. We're aiming for compatibility with the current version of Ruby. We haven't started work on the 1.9 development version, but we don't expect that most of the 1.9 features are going to be too difficult to support. Now, we've had a couple of releases recently. We're working on our big 1.1 release, which I'll talk about soon. So why do I think that JRuby is really an open-source success story? Well, the interesting thing about JRuby is that none of the original developers of the project are even involved anymore. There were a number of folks that wrote the original parser and the original interpreter and the original version. In fact, when Tom and I started really getting our stride on JRuby, that was pretty much at the point where a lot of folks considered JRuby was dead and that it was a done project. No one was ever going to actually make it work. That was probably about three years or so ago now. But in that amount of time, we've managed to make it one of the better Ruby implementations. The other half of this is that the vast majority of code in JRuby is completely from unpaid contributors. Tom and I have been working for Sun for a little over a year now, but we did two years of work before that on our own time, and almost all the other code in the system has actually been contributed from other folks. We're trying to get more people paid to work on it, especially since a lot of people are starting to use JRuby, but there's no way that JRuby would exist in the current state without lots and lots of contributors that have helped out. What we're seeing now is that some of the pieces of code and some of the frameworks that we've developed for JRuby are starting to see use outside of the project, and I'll get into that a little bit later too. A little JRuby design overview. Does everybody know how VMs and language interpreters are designed here? Some of this will be a review for one or two of you, some of the geek year of us, and the rest will be hopefully interesting for all of us. So the design of the lexer and parser, basically we have a handwritten lexer. It's originally ported from the C code, and it's had lots of changes since then, largely because whenever you take a piece of C code and port it to Java, you don't end up with particularly good Java. So it's been rewritten and it's pretty clean and performs a lot better now. The parser is also a port of the C implementation. The MRI here stands for Masa's Ruby implementation, a typical acronym we use to describe that. So we just ported the grammar and actually it was folks before us that ported the grammar over using J. I think we're one of only two projects in the world that actually used J to generate our parser mono being the other one. And as a result we get a parser out of it. And I don't really use the parser and I hate working on parsers so I'm going to move on. One detail, one little OSS angle for this is the fact that our parser has actually enabled most of the Ruby tooling that's out there. Most of the tools that are available or the ones that are getting wide use are written in Java and they basically all use our parser in our AST. Because it's open source they can just co-opt that piece of code and as a result we've ended up using Ruby support in IDEs like especially NetBeans but also in some of the eclipse based ones and in the others. So the core classes of JRuby in general we have a one to one mapping between the core Ruby classes and the Java classes that we implement them with. So we have a Ruby string and a Ruby array class that implements string and array. To make it a little easier to bind all those methods into Ruby Java annotations there's a few other Java 5 features that we're actually using and they've helped a lot. In a lot of cases we've just ported the existing Ruby implementations of those classes to try and match compatibility one to one and in other cases we've implemented our own versions especially in cases where the original implementation didn't map well to Java code. So I'll demonstrate just a little bit of what some of this code looks like just so you can see. All right, so here's a quick example of the annotation that we're using. We've got our Java method gsub and in order to bind that into our Ruby string class we have a gsub we have a JRuby method annotation and the annotation tells us what the actual method names will be there can be a list of those for alias methods how many arguments are required how many are optional and then various other characteristics that we can use to optimize it like whether we need to allocate a call frame for it things along those lines and this has made it a whole lot simpler to actually generate the code that binds a particular method into Ruby. Let's see, another good example of this would be a simple 2s method. So here's a method where we actually have two different names for it or in this case it's just the same method used for two different purposes and we bind it in and it's available in Ruby code so we'll go back in here All right, so just a little view of what it looks like to actually write some code for the Ruby core classes so the open source angle for this is being able to share a lot of the knowledge that we've gained about the way Ruby works Ruby does not have a specification and that's made it pretty challenging to actually implement the language. Doing these ports directly has helped us ensure that we're compatible with what Ruby does and at the same time we write a lot of tests and we help other people write tests and it's made it more specified, not completely specified but more specified than it used to be The port that we've done and the code that we've ported over makes it a lot easier for other implementations to figure out what's going on inside Ruby. Right now there are no less than four different Ruby ports that are under active development probably two or maybe three of those that are actually probably going to go somewhere and I believe almost all of them look at our code because the C code is a little bit difficult to follow and a lot of them are writing these things in object-oriented languages that are a little friendlier so another half of this is that we want to do as much of the heavy lifting once as possible Some of the contributors that we have here some of the big ones Ola Does anybody here know Ola or have heard of him, read his blog, he has a couple Ola did some of the early work on helping us get Ruby JRuby to run Rails and probably the biggest contribution was his implementation of two different YAML parsers YAML is a markup language that Rails uses for configuration and it's used in other parts of Ruby as well and his RBYAML port that was actually a pure RubyYAML parser that is now being used by a Rubinius which is a Ruby written in Ruby essentially and the JVYAML port that he did is being looked at by the IronRuby project for .NET so that they'll have a YAML parser so already we're kind of helping out some of the other projects Marson is probably the most amazing piece of porting work that I've ever seen we have had a problem in JRuby where the Java regular expression engines since they work with normal Java characters were a performance problem for us because Ruby's strings are all based on bytes and we figured we might always have to deal with that problem until Marson said I think I can probably port this Oniguruma library that they're using for Ruby 1.9 and porting any regular expression engine or implementing any regular expression engines a non-trivial task but Oniguruma is probably one of the most complicated engines out there largely because it allows you to have plug-able character encodings so you don't have to say what character you're encoding you're running this regular expression over if you can provide the plugin code that manages that encoding and I think it was in about October Marson said yeah I think I probably take a few months for him to get it done and about a month later he actually had it finished and all working and in a lot of cases it was faster than the original C implementation so amazing piece of work I'm actually hoping to work with and help Marson expand this so it can work with Java characters and possibly push this through as a replacement for the Java Regex library to cover some of the edge cases where it has some issues Tom very recently he's been working on a POSIX look-alike for Java is anybody here ever tried to do process management or any of those sorts of things in Java it's pretty brutal and it's the features available are just not what you need to actually do good process management even beyond that you talk about things like symbolic links and features that basically exist on almost all operating systems Java still doesn't have a way to support them so using this library JNA I'll talk a little bit about that later Tom has worked on basically a POSIX or libc look-alike for some of these features so that in Java code you can have access to symbolings you can have access to process control and I actually added fork to it which is a little frightening so then the pieces I've done most of them haven't gotten out into the general language implementation domain yet but all of the code generation stuff that we've done all the support to try and make dynamic languages run faster all the compiler tools that's mostly the bits that I've been working on and I'm hoping to start bringing that to a wider audience very soon so it can be general purpose for other language implementers on the JVM so the design of the interpreter JRuby's traditionally been interpreted just like the C implementation and we still have an interpreter right now at least for when we run an interpreted mode we have an AST walker like a lot of interpreters are recursively digs down into the tree and executes and currently most code starts out interpreted while JRuby runs this is to make it a little quicker to run evaluated code compiling is expensive and to allow for people to run with typical Ruby scenario where you have a bunch of source files on disk and you want to execute them and you want to run the interpreter for almost all execution so now the interesting thing for open source side of this is how rapidly this has changed new interpreters were the first three major contributions that I made to JRuby various rewrites in the middle we had a very slow and overambitious stackless interpreter which sort of worked you could do recursive fib to a million things like that and then it would fall under the weight of the slow performance and then kind of we settled on this third interpreter version it's the smallest piece of code and the smallest interpreter that we've had the simplest and actually the fastest so that's probably going to be the main interpreter for quite a while but we are also working on a byte code interpreter similar to Ruby 1.9 or Python to try and eliminate that interpreter engine as any sort of performance bottleneck starting out piece of code so the area that I've been spending most of my time on for the past nine months is working on JRuby's compiler in JRuby 1.1 we can compile Ruby code completely down to Java byte code and it's anywhere from two to five times faster than running it in interpreted mode and usually faster than all of the existing implementations of Ruby so the general idea is that an AST walker that's very similar to the interpreter just walks through the code and makes calls into a byte code emitter and that byte code emitter generates Java classes containing methods for all of the bodies of code it's not really a Java class that you can instantiate it doesn't look like a normal Java type but it's essentially just sort of a bag of methods that we then bind at runtime so that you can call them as byte code rather than through the interpreter and there's two modes that we run with you can do ahead of time compilation and take an entire application full of Ruby files turn them all into Java class files and run your application that way that ends up working out pretty well it doesn't save us much on startup because there is still class verification cost and loading all that byte code into memory but it does allow you to have everything compiled from start so you don't have to wait for it to jit that brings me to the second version this is what most people will run with in jit mode JRuby actually will run most of the code interpreted and it will watch to see which methods are the hottest eventually compiling them into byte code so as your application runs just like the rest of the JVM it'll eventually be compiled down and run a lot faster and from there then the JVM can take it and do whatever native code jitting it wants to do and that's helped us keep Ruby looking basically the same and feeling the same when you run it in JRuby and that's how you get performance out of compilation and it also makes it a lot more complicated to design but there's a couple different open source sides to this as far as I know nobody's ever done a mixed mode language implementation on top of a general purpose VM like this so it's kind of a new idea and it ended up working out well for us so Rubinius, XRuby some of the other implementations that are out there of Ruby have started to follow our lead in a lot of ways running with interpreted or byte code engines for a while and then trying to look at jitting things down and of course this isn't really a new idea but the idea of applying it to dynamic language like Ruby was not their first idea and unfortunately I and Ruby wishes they could but since we have a GPL license attached the poor Microsoft guys are not allowed to look at our code that's too bad but we talk to them and re-rib them once in a while about their open source initiatives so anyway moving on we're also trying to turn this into more general purpose compiler tools so any folks that are interested in other languages on the JVM will have less work to do to create them especially as regards making them perform well there's a lot of tricks that we've had to do in JRuby to make Ruby run well and we're trying to find ways to make that general purpose so that everybody can play with them on the other side we're working with a lot of the core JVM engineers and especially John Rose on improving the JVM for languages in the future John's very interested in at least for Java 7 trying to get dynamic invocation in so that it can be optimized so that you have a lot less work to do to make dynamic languages fast on the JVM he's also working on what he calls the da Vinci machine that's basically a multi-language spin-off from OpenJDK that will provide a whole bunch of other language features like tail calls continuations a lot of things people never expected to even see in the JDK or on Java are going to come to light in the MLVM and I believe that's what John Rose is working on full-time right now is adding some of those features and working on the dynamic language support so I'm going to show a little bit of the compiler and what the code actually looks like here if I can bring it up quick hopefully this font isn't going to be too absurd so in order to make this compiler easier to design easier to read and because I don't know anything about compilers it was designed to have two halves the half that actually walks through the AST doesn't know anything about the byte code generation at all it's completely separated from the code so here we have a compile method at the top of the compiler and you'll see what generally would look like a typical interpreter for each type of node it's going to call a particular method to handle it and if we look at the interpreter which surprisingly enough is named AST interpreter and we go down to the main evaluation method where the interpreter you see what's almost the same code alias nodes and all the other nodes are just defined as methods in a large switch so that's by design to try and keep the compiler reasonable and certainly more readable so then what you actually have once you dig into the code is you have this method compiler context and for each step of the way the AST walker will call into the method compiler to do something there's a number of core operations like creating primitive types creating methods just defining blocks of code and so it makes it a lot simpler to actually implement the compiler since the AST side doesn't have to know how to generate any AST code now to show you something a little bit more exciting and scary we'll actually show you what some of the code generation looks like let's look at the stack-based compiler so one of the things this allows us to do is to actually have a pluggable compiler system all we have as far as the as far as the AST walker goes is a set of interfaces and one of those is some sort of variable compiler for accessing variables and setting variables and we have multiple implementations of those to allow for various types of performance optimizations one of those optimizations is to use Java's variables rather than to create our own array full of a bunch of values so here we have a stack-based variable compiler and then we take a look at the code that actually does a variable lookup well here's a variable assignment that's an easy one given that there's probably a value already available on the stack we make a copy of it and we have a store operation and so in this way we can actually generate all of the bytecode that goes behind the scenes in JRuby and if anybody's interested in compiler stuff I'd love to have people look at this and tell me if I'm a total lunatic it works pretty well but it's my first attempt at a compiler and it's been an adventure are there any compiler designers or compiler writers here there's not a lot of us around so and two years ago I didn't know anything about writing compilers, designing languages, VMs none of that so any one of you within the next year or two could be writing compilers too aren't you excited about that okay so talk a little bit about some of the compiler performance optimizations we've done and this is a little dry so I'm going to move through it pretty quickly caching literals is kind of an old trick trying to use Java opcodes as much as possible for various language features and then local variables kind of fits into that too trying to use Java primitives Java systems for as much as we can we've also got some basic inline method caching just to speed up method look up and to make it a little quicker for dynamic invocations and lots of stuff that we can play with lots of areas we can fiddle with it and improve the performance over time so another way that we do some optimization is in our core classes I mentioned that they were ported from Ruby one of the ways that Ruby gets what performance it does have is by having copy on right implementations of strings and arrays has a fast hash implementation and then we also started using all of the Java new I.o NIO library to do our I.o implementation so that it maps directly to the way Ruby works and I tell you one of the biggest challenges in this moment what's essentially Lib C I.o with all the NIO classes and then JNA I mentioned a little earlier is a native layer for calling into C libraries turns out to be a whole lot faster than actually shelling out to CH mod for example it's not too surprising and then of course the regular expression implementation I talked about the Onigaruma port named Joanie that Marson did so the open source side here is probably the most interesting in the regular expression area again we've been through four different regular expression implementations for JRuby trying to find one that works well for us of course we started out with a normal Java regular expression library but the Java.regex code will actually blow up if you do an alternation over a large content because it recurses and so it's really fast but it also doesn't work for a lot of types of input so we started moving to JRegex which is a third party regular expression library with more of a compiled engine but it is also character based so it was much too much encoding and decoding overhead for us to be able to make it work then we really decided we had to have a port of a regular expression engine that would work well for us the first one that was started was a direct port of Ruby's regular expression engine and it wasn't as fast as JRegex but it did save us some of the encoding and decoding overhead of course once we had Oniguruma there was really not really no other choice and it says here in progress but it's going to ship with JRuby 1.1 and it's basically done and it did turn out to be the holy grail for us so the POSIX stuff anybody that's done any Java development and tried to work with lower level parts of the system but Java's APIs are a lot of them are pretty far behind the times process management there just really isn't any good way to do in Java you can spin up processes and hopefully they'll run appropriately and you'll get a result back but if you want to be able to control them or send signals or do IO, normal IO to processes it's terribly painful the file system operations are also a big one that's a problem for Java you cannot work with file descriptors directly you can't change file system modes you can't change ownership you can't even work with symbolic links even though they've been around for, you know, decades now so we ended up using this JNA library it's not JNI, it's called Java Native Access it essentially allows us to programmatically call into any C library from Java code without writing any C code at all so we use this to load in libc for example to be able to make multiple calls to symlinks and chmod and other functions that are available there if you've ever used Ruby it's similar to the DL library it lets you just call into any arbitrary C library and then we've also started using IO to emulate libc IO behavior and it's an adventure reading glibc code to figure out how it works so back to some now we get to some use cases here to kind of talk about where JRuby is being used one big use case and it's unusual that this is such a big use case but it's doing GUI applications with swing the big problem with swing the standard GUI library for Java is that it's just too complicated and really when I say complicated it's not designed for humans to be using directly most of the time it's just too large and it's kind of it kind of should be a lower level library of application framework on top of unfortunately none of those application frameworks have really ever materialized so people still write raw swing code Ruby actually makes swing a whole lot easier and a lot cleaner and easier to understand and it makes it easier to build some sorts of application frameworks on top of it so I'm going to do a quick demo of what it looks like to do swing stuff in JRuby using a interactive console here is everybody in the back there too that's good enough so this will be interesting to try and type and talk at the same time okay so like most scripting languages or dynamic languages Ruby has a little interactive shell called IRB our version of it is JIRB because naturally we have to stick a J on the beginning of everything this is running under JVM so obviously we should be able to pull in Java code and so I'll just require in Java the Java library we have the false there means it was probably already loaded and I think that's a side effect of JIRB but then we can actually start calling into normal Java code directly so if I do java.lang system out print line with some text you see that it actually writes out and what's more like normal Java code so for example if I want to pull in some swing classes we'll import them Java X swing J frame we know that swing is awake and then I'll construct a frame here using normal Ruby syntax with some title okay so we get our wonderful swing logging output there and this is all live code and live objects so we'll show our frame and it should be in the back here somewhere there so there we have our little frame and I don't want to have to keep clicking over there so we'll do always on top it's true and it's always on top and we will set the size to something a little bit more viewable I'll say like 400 by 400 okay so here's our window and of course it's a frame that has nothing in it so it's not particularly interesting we'll import another class here Java X swing J button and I'll make a button press me and add it to the frame okay now in order to lay itself out we'll have it show and we've got the button in there so we can actually do something so we will attach an action listener to it and now the nice thing about Ruby is that since we have closures we don't necessarily have to create a whole separate class to implement an action listener we'll just pass a closure into it and Jerry will do the magic of creating a class for us behind the scenes so here we have our button and we will add and notice that this is all Ruby standard syntax for these we do support the uppercase or camel case versions of all these methods but when I started looking at code that had all the camel cases in it next to the regular Ruby code I realized that it was a little ugly so we ended up adding the ability to just use underscore casing so it fits well into the rest of your Ruby code so I will add an action listener but what I'll actually do is I'll just give it a closure and that closure will take the button and set the text to something new okay so we've added our action listener and now hopefully if it works right there so that's a little bit easier than actually implementing a class for an action listener right and you can do this with basically any Java library too we try to be as smart as possible about how you measure into a class implementation of course action listener only has one method on it but if there were multiple methods you can specify parameters to the closure that say which one was called and so you can have a single closure implement an entire class for you makes it heck of a lot easier to do a lot of swing stuff so go back to the slides here this is going to bug me so I'm going to get rid of that alright so you can see kind of see why a lot of folks are interested in using Ruby to do swing development there's actually some people doing commercial work with it the second use case that really has helped Ruby come into the mainstream is web development and of course classic Java web development is a little bit too complicated it's never really found the framework that makes it easy or pleasant to do Java web development and it turns out that almost all the new frameworks that people are writing for Java and for other languages are kind of following Rails lead now Rails has really made it a whole lot simpler to actually develop web applications so the natural case for us in JRuby was to get Rails running on Java Rails also improves on a lot of Java web application development because it's so over-configured in the Java world you can essentially do anything but you have to write configuration that would do almost all of it and of course Java tends to be a little too verbose for a lot of work that you do on web applications a third use case that a lot of people have been using JRuby4s for doing test-driven and behavior-driven development these are kind of ingrained into the Ruby community but it's really damn hard to do test-driven development in Java if you have to have all the code compiling to run it being able to use a dynamic language like Ruby to do test-driven development means you can write all of your tests and you can run them and you can see there's failures because the code it's testing doesn't exist yet but then you can go and fill in the blanks you can start actually writing the code that goes along with it and in the case of JRuby you can actually write code in Ruby that tests all of your Java classes so we'll take a look at two examples of how this actually looks here is using the test-unit framework this is a standard testing framework for Ruby but we're actually pulling in a Java class, server socket and writing some tests against it and now if we were living in a world where a server socket didn't exist we could still have this code and we could run it and we could see that it fails because server socket isn't present and then go on and continue from there letting the test drive our development in this case we test the server socket by constructing it and making sure it has the port that we specified for it this is simpler a second example here with also using server socket is using RSpec RSpec is sort of a behavior-driven or specification-driven development where instead of expecting you to add comments to all of your tests or to all of your code the specification itself actually has descriptions of what's going on so it does do tests and it does test your code like a regular testing framework does and you can jump out all of the text all of the specifications that you've written and that lets you say server socket should know its own port or server socket should know its own port comes out of the RSpec tool as a specification document for server socket so I got about 10 minutes left on the normal talk and then I want to have lots of time for any questions so a few things that I'd like people to take away from this having Ruby and really having lots of languages on the JVM but having Ruby on the JVM opens lots of possibilities it's finally making a lot of these Java APIs which have really outstanding APIs and outstanding implementations a lot more approachable when you make APIs that are going to stand the test of time you sometimes make them a little more complicated than they need to be they need to be flexible, they need to last forever and Swing is still an excellent API for doing GUI work it's just too damn big to do in Java code Ruby also fits in really well with a lot of the existing libraries taking the example of Swing again it seems like just a natural fit and especially since in the Ruby world there is no really good cross-platform way to do GUIs being able to use something like Swing is a natural fit for it and JRuby really is more than just a Ruby implementation we're trying to open up Ruby to all of what's available in the Java world all of the libraries, the outstanding VM all of these pieces that don't really exist in the Ruby world we're trying to push Ruby forward a little bit too trying to find a way to make Ruby as natural on the JVM as any other language and of course we really thrive on open source development and we really hope that anyone that sees our talks or tries JRuby or plays with it will see how they can contribute and it's really not that difficult as much as possible and from that here's some more information JRuby sites if you're interested in NetBeans I mentioned it's one of the best Ruby IDEs that are out there it really does some amazing things with code completion right now and it's getting better every day there's the link for it Ruby if you need more information on that seems like most of you probably know Ruby but there's a link for it and really if you want to talk more about this there's a link on FreeNode and we have folks in there 24 hours a day that are awake and talking about stuff mainly because the entire team is scattered over the whole planet and we'd love to hear from you and I'd especially love to hear from you individually if there's any questions you have or any thoughts you have about JRuby so there's my address and feel free to email me we're ready for questions, thanks any questions at all do we have JVM stuff the one right here is there a microphone going around or is this one work so the question was do we have any plans to support Ruby 1.9 yes we do right now we're focusing on in the 1.1 release getting Ruby 1.8 stuff to run really well most of the compatibility issues have kind of been wrapped up and the performance is looking great we're trying to solve a few more bottlenecks if we want 1.1 out we will start supporting Ruby 1.9 features at the first you'll have to specify a flag that will turn on all 1.9 features and you'll be running in 1.9 mode but I'd like to have individual settings so that if you want just Ruby 1.9 support for a literal lambda syntax for example you could turn that on and still have the rest of Ruby 1.8 intact and that's one of the big things we're going to be working on after 1.1's out probably by the end of the month alright other questions front here thank you what is the most important feature from the MLVM projects besides GSR 292 that would give the best performance boost to JRuby and other dynamic languages so what is the most important feature well GSR 292 for those that don't know is the invoke dynamic GSR which intends to add fast dynamic invocation to some version of the JVM and hopefully we can get it into JDK 7 the pieces that are being added to GSR 292 are definitely the most important and the ones that we're trying to get out there dynamic invocation along with the ability to create lightweight method handles a number of other features that make it simpler in the multi-language VM what would be the most important I suppose it depends which language you're implementing for the most part the ability to do tail calls and have the JVM optimize them is going to be a big one for a lot of languages and the lack of tail call optimization is one thing that's kept a lot of functional languages from being hosted well on the JVM so that's probably going to be the biggest one it's the showstopper that stopped a lot of other languages from getting into the system I would I would say that they're probably all going to be just about equally important because they all enable some type of language or some type of optimization that's going to help it John Rose if you look him up, he's got a blog where he's been talking about things like tail calls continuation support and he has like prototypes for all the stuff in his back pocket continuations tuples a bunch of other optimizations one other one that I'd really like to get into the multi-language VM is something like JNA native library that lets you call C code as standard as part of the JDK so that not only can everybody use it to call arbitrary C libraries but it'll optimize it down so when it eventually jits the code it just becomes a call to the C library directly lots of cool stuff could come out of that alright right here I remember reading a few months or maybe a year ago someone's opinion that was going to be very difficult in JRuby to implement continuations but from what you're saying it sounds like you've managed that how did you do it and is it actually done in JRuby we do not support Ruby's continuations because we can't manipulate the Java call stack directly there's no way to do it on current JVMs without taking a massive performance hit and both JRuby and IronRuby which is for CLR have opted to not implement it but we do have some continuations right now lucky for us continuations are so slow in the C implementation of Ruby that nobody really uses them for actual work so the vast majority of code out there 99.9% doesn't use continuations and all that said we would like to be able to support continuations and really continuations little brothers co-routines in a future version of JRuby that support is probably going to get into MLVM into the DaVinci machine at some point so that we can do efficient co-routines on the JVM yeah one more up in the back there and you can come up and talk to me after and I'll be around so I'm not too versed in dynamic languages but I have doubled with compilers a bit in the past and besides just getting the compiler to work resulting code to perform sometimes smaller issues like actual compilation speed or the quality of the error messages that are especially in the first implementation not as good as usual could you comment on that that you have to put in a lot of work in getting a decent error generation from JRuby to compilers well I'm hoping to be able to take what we've done with JRuby to make it easier to write compilers and maybe an eventual goal similar to what Microsoft guys are doing with DLR where you don't actually have to write the compiler you just write an abstract tree that represents your language and a compiler pops out the other end that's an ambitious goal but at the very least I want to take what we've learned from writing stuff on the JVM so that for example you don't have to be doing a lot of raw bytecode emitting yourself you don't have to be doing your own stack management and for example regular exceptions are terribly difficult to wire in correctly if you've never used them before so we don't have a whole lot of facilities in JRuby that would be general purpose right now but I think the design that we came up with for our compiler could be expanded to a purpose code generation library for the JVM I didn't mean really mean code generation just pointing the right token that causes an error during the compilation process for instance because that's quite often a somewhat forgotten part of building compilers we haven't really done anything specific in that area so I'd be interested in hearing what sort of specific problems you're talking about alright and I think that's all the time we have I'll be around so feel free to talk to me and thanks