 Hi, everybody. Howdy. We are going to do our yearly JRuby talk. It's kind of amazing to me now that I've actually done JRuby talks since RubyConf 2005. But I think every year we have some new stuff and a new approach and some new interesting demos to show. So we'll dive right in. We are the JRuby guys. I am Charlie. And I'm Tom. And Nick Sieger, I'm sure, is here somewhere. But he's going to be doing JRuby on Rails, our presentation on Sunday. So we're taking the main talk for now. Here's all contact information. You can feel free to email us anytime if you have any questions. And so I mentioned Sunday. On Sunday, we are going to have our first ever JRuby Conf. Yay. Great. Really excited about this. We're really happy, really thankful to Ingenyard for making this happen, especially in such a short amount of time. I think it was just late August. We talked about it. And then within two or three weeks, we had everything arranged. It's a free event. So we love for everyone to come. We want everybody, as many people as possible, to be involved. And unfortunately, if you have not already registered for it, it is, quote, sold out. It's free. So it's really sold. But it's going to be really exciting, really a lot, just a ton of fun. And we're really humbled because we had 100 and some people. We had 100 and some seats available. And it sold out like that, five hours. I think we sold out faster than RubyConf for that. Added another 100 and some seats. And again, it was just gone. I think that was just ate up the rest of the wait list. So pretty cool. We're going to try and do these and attach them to more events and do more of them over the next year. And hopefully, we'll see you at one of those if we don't see you on Sunday. OK, so what have we been doing since last year? Well, things have been moving pretty fast. We've had three major production releases, 1.2, 3, and 4, thousands of commits. I think the 1.2 release and the 1.4 release each had well over 1,000 commits each. Lots and lots of work on compatibility. That has been the primary focus over the last year. But now starting to lean a little bit more towards job integration work, making sure that that side of things is absolutely seamless, performs really well, does everything that you would ever want to do with Ruby on the Java platform. Lots of memory and startup time improvements. Startup time is one of our classic problems. We'll mention that a little bit later. But we continue to try and find ways to improve it and slowly knock it down a little bit more with each release. And memory is always an interesting thing on the JVM. There are ways to do pretty good memory efficient applications on the JVM if you spend a little bit of time and actually look into how much memory you're using. And of course, in the past year, in just the past few months, actually, we have moved now to Engine Yard. Engine Yard is now sponsoring JRuby development. Thank you very much. We're very excited. And I will cut off the main question we get about Engine Yard. Yes, it has been great. Not a whole lot has changed. Day-to-day development stuff. The big advantage we have now is that they're making things like JRuby Conf and JRuby support offerings and JRuby in the cloud all possible. So really happy with the Engine Yard so far. OK, JRuby 1.4 is the most recent release we have. Released it on November 2 after about a month's worth of RCs. 300-some bug fixes in that. It went up a lot during RC stuff, cleaning, remaining things up. Now, 1.8 support is now based on Ruby 1.87. We decided to make that move just because Rails 3 is supposed to officially require 1.87. Snow Leopard ships 1.87. Most of the Linuxes have been shipping 1.87. So it made sense for us to finally make that move. And I think it took us about a week, week and a half to get the basic 1.87 stuff done. Thanks a lot to Ola Beanie and Marcin Rielzinski for that. We've done a lot of improvements to the 1.9 support, but it's a little tough for us to tell even what 1.9 is right now. The specs aren't quite complete. Nobody's really sure about which features have changed between 1.91 and 1.92. So it's not done, but we're going to be working real close with the 1.9 team and Yuguie and everybody else to make sure that both the specs are up to par and that we pass the specs. Hopefully have our complete 1.9 support around the same time that 1.92 comes out. With that said, IRB starts up. You can start up a Rails application, generate a Rails application, gem install. So it mostly works. Right, right. We're fairly hard on ourselves, but it's pretty good to have all that stuff working as well. We also have now an installer and a native executable for Windows, and we realized over the years that we realized that we've been basically ignoring the Windows platform because we don't really like the Windows platform. But the interesting thing about Windows is that most of the world's developers are actually still running Windows for their stuff, especially in the Java world. And since JRuby bridges that gap, it makes a lot of sense for us to do a little bit better support for Windows. And so JRuby 1.4 had that. We're also gonna have native executables for other platforms, all platforms, in the 1.5 release as well. So the bash scripting hell that we have currently we don't have to deal with. I mentioned a lot of the job integration improvements that we're working on. Performance, additional features, trying to bring up parity with the other JVM languages. Another nice feature in JRuby 1.4 is a totally new embedding API for the Java side. Much, much nicer than what we had before. It's now the official JRuby embedding API, it's what we recommend that most people use unless you wanna use one of the standard APIs like the Java scripting stuff or bean scripting framework. And it's so much nicer than what we had before. Yeah, we can't say this enough. It's really, really a lot nicer for embedding. In other words, it doesn't completely suck. Yeah. Olabini did his fourth YAML parser implementation for us. This time, a bug for bug port of SIC, or SITE, the YAML parser that Y wrote for the core of Ruby. And now we have no known YAML bugs in our tracker, finally. So I think we're finally on par and compatible with MRI's YAML support. Lots of memory reductions I mentioned. We've updated RubyGems, Rake, RSpec, we ship all those with JRuby every release. And various little focused performance fixes like for IO and for job integration. A little note on compatibility. We run more tests on JRuby than any other Ruby implementation. We run the Ruby specs. We run the suites of tests from Ruby 1.8 and 1.9. We run the old Rubicon test suite. We run a bunch of our own tests for job integration and for little JRuby specific Ruby features. About three or four other test suites. And I think that's helped us a lot in maintaining compatibility and improving it over time. We also run continuous integration on several different JVMs. Java 5, Java 6, and Java 7 versions of at least four different ones. Oracle, IBM, Suns, Hotspot, and Iced Tea, which is the red hat version of Hotspot. And then every night we have a 30 minute full run that tweaks all the different JRuby settings and makes sure everything's working well. And unit tests for things like Ruby on Rails. Right, right. So we're pretty brutal as far as doing the continuous integration. And I think that box is probably keeping my basement warm. There are many compatibilities, as a lot of you may know. We're missing some POSIX behavior. We've added a lot over the past year and gotten a lot of things working well, but you'll probably never be able to safely fork the JVM. We don't have continuation support. It may come later with some JVM improvements and enhancements for adding continuations at the VM level, but for now we do not support them. Startup is obviously always a constant pain. We start up faster than just about any other JVM language at this point, but it's still a half second to a few seconds if you've got RubyGems loading. And there's more that we can do there. And we can't run any native C extensions. Now we don't rule out the possibility that a cleaned up subset of the C API couldn't be implemented for JRuby in the future, but for now your options are to use one of the Java based equivalents like we have ActiveRecord JDBC, we have our own YAML, we have our own Zlib, et cetera. Or to use FFI if you really need to use the native library and just bind it through FFI and then it'll work across all the implementations. Okay, and I'll hand it over to Tom to do his Carnival of Venice demo. Okay, so we always do IRB demos and we always do the same IRB demo, so lately we've been trying to JRB, that would be bad. Okay, so the first thing we're gonna do is we're gonna go and load in some Java stuff. In fact, we're gonna load in Java support itself. Yes, sure. Okay. So, next thing we're gonna do is we're gonna actually load in a Java class and it's gonna be a MIDI class. And this is the second time I've done this. So, it might be a little slow. Okay, so we load in this MIDI system class and we define a constant in this namespace. So now let's use it, create a synthesizer. This is a standard library that ships with all the JDKs. So if you've got a JDK on your system and there's MIDI support, you'll have access to this MIDI library. It's such a cool demo. All right, so now let's open this synth. Let's see if it takes focus there. Open it up, now we get a channel so we can use that channel to make beautiful music. And so this, oh. Go ahead, go ahead. This line is really interesting. Synth channels are A-rep zero is actually Java calling git channels and then it's returning back a primitive Java array but we still can index in it like it's just a regular Ruby array. This is an example of all the stuff that we try to do to make Java feel a lot more like Ruby. Other than the import and the Java package, really there's no code in here that should look too much like Java. It's all made to look very Ruby-like. So now I'm gonna go and create a J-frame. And there's a whole bunch of statements there that's gigantic, impressive, bad thing. So now we're going to set the size of 600 by 100 and let's actually just show it. So there we go, we got an empty frame and it's bare glory. Another thing that I wanna do is I wanna actually change the layout manager so that when I'm adding all these buttons that I'm about to add, they'll actually just flow across the screen. Not surprisingly, it's called flow layout. All right, now I'm gonna totally cheat because it would have taken me another 10 minutes to type this in. So the first thing I have is a hash here. The key is actually the MIDI tone and the right side is the actual note that the tone's for. So 67 is the note G. And then we're gonna iterate over each of these and we're gonna create a button for each note with the right label. And then the most interesting part here is this add action listener. We're gonna add an action listener for each button to go and play that particular note's value. You play that note's value and there's a value can't be 99 how hard you hit that button. And then we're gonna go and add that button to the frame. So another interesting JRuby feature here is add action listener actually expects the Java interface but instead of actually implementing an interface, we're actually just gonna pass in a block. And JRuby's happy to go and accept that block as the interface and pretend it's that interface. All right, so now we're gonna make it visible. And then we're gonna get to the truly exciting part of this demo. I'm gonna play Carnival of Venice. All right, ooh, okay, it works. Since none of you are my parents, you didn't need to call me. So this gave a pretty good example of how you could go and pull in Java classes and they pretty much feel like JRuby for the most part. Right, and there's no additional JRuby code. There's no wrapper library here. It actually is really, really fun to use these libraries from JRuby without any additional work. If you wanna do some nice JRuby metaprogramming magic and wire up the library a little bit more cleanly, it just gets that much better. So it's a great example of how much fun this can actually be. All right, back to this. Okay, so that's a quick little taste of what JRuby looks like. Now, I love you guys to death, okay? I really do, this is my favorite conference ever, but I always feel like I have to do a little bit of justification for where JRuby fits into the whole Ruby ecosystem. And JRuby, I think, really is kind of the enterprise Ruby and that's the way that a lot of large enterprises, especially ones that have Java already, are going to get into Ruby. And you know, you don't have to be afraid of these guys because they have lots and lots of money, all right? Who here likes money? Okay, okay, that's good, that's good. Who here likes Ruby? Okay, so if you like Ruby and you like money, the enterprise wants to pay you to do Ruby. So it's a perfect opportunity. And we'll dig into this a little bit and analyze what do these enterprise guys really want? Okay, so what the enterprise wants? They want things that they can just fire and forget for their deployment stuff. And ideally somebody who knows absolutely nothing about how the application works, how it's supposed to be deployed, well, they'll know the deployment stuff, but they don't know what's happening under the covers. That's what they want. They want to toss something over the fence to their production staff and it just goes out and gets deployed. So that's one. They want long uptimes. Once they get this app up and going, they don't want to have to go back to their production staff every other week and re-toss something into production necessarily. So you want servers that are gonna run forever, that are gonna be able to run for as long as the application is satisfactory on that revision. So that's another one. They generally have locked down servers. You're not gonna have compilers, you're not gonna have development headers, things like that. You really need to be able to deliver to those servers a complete package that's all built and all ready to go. Because they're not gonna put compilers, not gonna put GCC on the production server that's facing the world. In a lot of cases, they want Windows. And again, we finally have realized that we can't totally ignore that side of the world. And Windows has done a lot to improve. It's not going to go away and we're gonna have to deal with it and make sure that JRuby works really well and that Ruby stuff can deploy on Windows servers for folks. We're going to embrace and extend. We are going to embrace and extend Windows. Yes, exactly. And of course they have lots of legacy code, legacy libraries and applications out there. Especially if it's a Java organization, they probably have all sorts of models and services and other things that they want to be able to easily consume from their application. And so of course, JRuby to the rescue. You are able to deliver all of this stuff with JRuby to the enterprise without having to compromise the beauty and power of Ruby itself. You can deploy to any Java application servers. We've got all sorts of production deployments of Rails just running on JBoss or any of the other app servers. You don't have to deploy that way, but that's what those guys like. So we'll just fit into their world and do our own thing. You can use any Java 1.5 or higher VM. And there are several options. There's at least three major production versions of Java and lots of little ones that are partial implementations. You don't have to recompile anything. You just have one file, send it to the server, it's done. There's nothing that has to rebuild on the server. It's all ready to go. And it all works even better on Windows than it ever has before. I think JRuby may actually be the cleanest way to run Ruby on Windows right now because we've spent a lot of time, a lot of effort improving and fixing all the little bugs that drive people nuts on Windows. And of course, you can use either Ruby or Java libraries. So all of the legacy stuff that's out there, it will just work. Like the MIDI library we just showed, you can pull it all in, call the libraries and you're all set. All right, so I'm gonna hand it over to Tom and we'll talk a little bit about probably the most important aspect of JRuby, the fact that we have the JVM to leverage. So for the next few slides, we'll intertwine some demos with some fairly heavy slides and why we actually think the JVM is a great platform to build on top of, particularly for Ruby implementation. For starters, Java's incredibly mature. You might say ancient. It's a decade and a half old, but not only is it a decade and a half old, there is literally an entire building on a sun campus where for the last decade and a half, engineers have put a century's worth of engineering effort into making the JVM rock solid and fast and easy to debug. And because of this, there's frequently people in the Java community that advertise having uptimes of one year or more and it's like, when do they upgrade? But maybe they don't need to worry about it so much. They're up for a year. And of course, these people don't stop working. They keep improving the JVM. So when we went from Java five to Java six, running a particular benchmark, we'll frequently see between 10 and 25% improvement consistently. So we get all that for free just because we're on top of the JVM. And as Charlie mentioned earlier, there's different implementation of the JVM by IBM. There's different implementation at Oracle and then the implementation we know best, and these guys are all competing to be, to have that crown to be the best implementation. So you think about each of these JVMs has another whole building of VM engineers working on it and they all are fighting back and forth to run JVM better and that's great. Like go for it guys. You just keep that fight going. So it's still a really good environment and there's tons of tools. And with that said, I'll do a demo of J console. Let's see. Yeah, that's the one. So I'm gonna start up the script. We'll go into it in a little bit. And then we're gonna go into J console, which is a nice tool to actually connect up to a live running JVM and look at stuff. So here I can connect up. Wow, it's so much faster in your machine. Get it. So you get some nice graphs up front. How much memory are you using? The fact that we've loaded 4,200 classes, CPU, go over to the memory tab. This is really useful for debugging because you can look at various generations in the garbage collector and go, oh, why is there so much memory that's surviving? Wow, I wonder if those are empty. Yeah, that should be. Thread window, which isn't really so useful in this, just use a Java debugger. It's another great tool. There are many great debugging tools. Classes loaded and then some nice textual description. Okay, but the cool thing about J console is JMX or Java management extensions. JMX allows you to go and define these managed beans or M beans. And in these beans, you can define attributes for reading or writing information to your live running system. You can define operations to affect behavior. You can get event notifications. So your memory is starting to get up there. It can actually fling an event for you. And then the standard tools like J console can actually go and manipulate and view these things. So we actually have used this internally for JRuby. So let's look at some of these. So parser stats, we have a bunch of attributes. So we parsed 250, 70 valves when the script started up and we did basically 73 requires. Pretty useful. We're going to look at JRubyJet. We compiled 39 methods and we decided to fail in one of them probably because it was a huge Ruby method and there was no benefit to actually doing that compilation. Then there's this thing up here, the fault domain. And now we start to get into the script. So I'll pop over to NetBeans. Another good tool for Ruby and Java. Okay, Jmxafkin and I have been on and off working on the script to go and make Jmx more palatable from Ruby. So we define, you can define your own mBeans. So here's a mBean that defines three operations. Two which double. The whole point of showing this double is that it has its own type system, which kind of sucks, but Jmx is so useful, I'll put up with it. And then we have a frackle operation and I'll just calculate a frackle. So let's go back into Jmx and see how this manifests itself. So if you look at the operations, there's the three methods, double three. Hey, we get six, that's cool. Double string, string, string. So this is all just built into the JVM. Call back and forth to a running JVM, register these beans, do monitoring, management, all this stuff, and it's for free. So now I'll calculate a frackle. Oh my God, is that a sorry looking frackle? Non-fixed with phone, that's simple. I actually had to screw around with this for a long time to figure out something that would display nice and non-fixed with phones. There you go, but you could go and make any operations or attributes you want to affect your live running system. This is a nice thing to have in Ruby. All right. The JVM is also pervasive. Obviously, every major platform that anyone here uses has JVM support for it. In fact, I'm sure it's already installed on there. A couple of funny stories. We have, I think, two bugs for OpenVMS open right now. Anybody here using OpenVMS? The other, yeah. Oh my gosh. Two people. Oh, those are probably the two bugs. I'm not really sure when we're gonna be able to fix that. If you guys wanna talk to us later, as potential testers, that'd be great. We also had a guy come up to us at a conference and talk about running a Ruby on Rails application and I'm not making this up on an IBM CMS mainframe connecting to a Microsoft SQL server. That poor bastard. And in fact, we also run on cell phones, including Android, which is... All right, so I'll do a little quick demo. I don't have the actual phone hooked up, but I will show the emulator here. I assume I will show the emulator. There we go, okay. So here is the little Android emulator you get with the Android development tools. And there's been discussion about, oh, we have Ruby on mobile and we've got RoMobile and people talk about Mac Ruby maybe on iPhone. But JRuby works well on iPhone as well. And actually, there's no actual modifications required to JRuby to get it to run. So let's take a look at my apps here. I have an IR, oh, I want that one, DevTools. Let's go back here. And okay, so I have, let's see if I can zoom in for you guys, IRB actually on the phone here. All right, so we'll run that, zoom back out a bit. And okay, so we get our little IRB terminal here. Very, very simple with just the text field and then some label output here. But I mean, it's just an IRB session. And this is actually running JRuby. It's doing, this is real IRB that's running. And let's see what else we can do. We can actually do things like pull in Java libraries. So this takes a second to do on the emulator. Yeah, it's really super dark. All right, I can zoom into that. We'll continue when we're done. Oh, yeah, now it reads nice, right? Wow. Yeah, the projectors seem to be a little dark. But we can kind of see. I wonder if I can, I can't highlight anything. So that's, here, we'll go even larger. We'll go even larger. Require Java. Oh, there we go. You can see it, right? All right, so I'll type blind.lang.system.get. I'm typed, I'm typed, it's up here. It's off screen and he's really confident on his typing skills. There's the rest of it. See that? Home there. And now I will go down here for the magic effect of running it. Ah, it works. So we're actually calling it a Java libraries on Android with Ruby. So there's more work to be done here to make it viable for building large applications, improving performance, reducing the size of what you distribute. But it works pretty well, works pretty well. And if somebody wants to see it on the phone, I actually have it on the Android phone I have, like I can certainly show it to you later on. Okay, so back to Tom, I believe. Okay. All right, so this slide demonstrates another awesome thing about the JVM, which is hotspot. Hotspot's a dynamic, optimizing, dynamic, profiling, optimizing, that's a mouthful. So you start up an application, JVM and hotspot starts collecting information about what you're running, calculates the hotspots, and then applies optimizations to that code. So if we first look at the green and pink lines, that's Ruby 1.8 and Ruby 1.9 too, you can see that they have straight line performance. It always stays the same because they have a static set of optimizations and they're not learning through profiling. If we look at the yellow line, that's J Ruby, you can see when it starts it's a little bit slower in 1.8.7, after the first iteration, it's now between 1.8 and 1.9. Get down to four, it's kicking ass or whatever. But then you get to six and you see this down tick and you think that like I started up some extra process, but that's not what happened. It's actually hotspot de-optimizing some code. And this is the coolest aspect of hotspot, believe it or not, maybe ironically. When you actually perform an optimization in hotspot, you put a guard in front of it. And this guards a very simple check to say, to the assumptions we make, hold true. If they don't hold true, then you de-optimize and go down the slow path. But if it does work out, then you can do these super aggressive optimizations right away up front and you might have a huge payout. And if you don't, you'll get a little ticked at iteration six, but it'll improve again later because it'll do other optimization. Ah, all right, next demo. I've been playing with a library called JRME. It's based on this two Java libraries, JMonkey Engine and JME Physics. They're hardware accelerated and whatnot. There's three goals, iCandy. How much can we go and play with the sophisticated Java library and make it look nice and ruby? And can you actually make a 3D game and ruby and have it run? And the answer was yes, it was madness. Ah, I got it, all right, let's start it up. Okay, so the game, the goal of this game is your this ice cube and the ice cube's solely shrinking. Ah, crap. Can people start to see that? You can kinda see where the ice cube is at the bottom. I don't know what's with the projectors here, but. Okay. Go for it. So I'm gonna move off. Every time I go and hit a direction, I add some force to it and then I'm floating, uh-oh. Okay, all right, let's try this game. All right, I think I can. Ah, these little bouncing yellow balls are pretty nice. Oh, depth perception sounds so good. All right, I think I'm big enough to make it over the gap. Ah, I can be bigger. Oh, if you hit a blue one, you go back to the other side. Well, I gotta make for the red one. So the cool thing is this is about 250 lines of code. I did have to make some library code around it, but that's generic library code and I'm not gonna count that code on the count. So you define a madness class that extends the physics game because we don't want physics. And this is actually a Java class. By extending this Java class, we actually have to override two methods, simple init game to go and set up the domain objects. Here's an example. Every half a second we shrink the ice cube by a centimeter. And then there's a simple update method you have to implement which just updates stuff like, we have the camera like follow the ice cube around. By request, I'm showing you the data format for this game. That's a level order and you might be able to tell that this is just literal hashes that are sort of nested in each other. There's even the ever so crazy here doc in the middle of a literal hash. In the text format, if you kind of remember the screen layout, there's the camera, here's the player, these are the bouncing doublers, here's the bumpers and so on. So kind of cool. Also there was a domain specific language sort of made for this library. So a bumper is made out of a dome, it's made out of rubber, it's yellow and it's out of particular location. All right, jumping back to slides. I have a feeling we're slowly running out of time. Okay, so garbage collection is truly awesome on the JVM. I think half that building are GC engineers and they've been working on it for 15 years again. We actually met one guy who his job is to work on one generation of one of those collectors. That's what he does all day long. The obsolete one. Yeah, the obsolete one. And there's two or three other guys that work on other ones, so bizarre. It goes back to the enterprise question. If people have money, you'll work on anything. Yes, yes. So all the collectors are incremental, so collection gets broken up in the smaller discrete phases to reduce pause time. Some of those phases don't even pause execution. They're all compacting so you can relocate memory so you don't get memory fragmentation and your Ruby process stays up more than three days. They're generational, so objects that survive past a certain time get promoted to a different collector, but then all the young objects can get wiped out incredibly fast. Parallel, you split your GC across multiple threads to reduce pause time. Concurrent, it'll also do it across threads, but it won't pause that execution at all. I don't know how they do it, but they had 15 years to figure it out. Yeah, black magic. And that was GC in 30 seconds or whatever. And we think we have the best GC of all the Ruby platforms. Here's a little graph. We just kept running gem install rake over and over again with different heap sizes from 32 megs to 512 and then we just tallyed up how much time GC took. Most impressive, this actually took about 11 seconds for us to run. Our dock generation is really slow for some reason and it generates a lot of garbage, but 0.5 seconds out of 11 seconds for total GC time is pretty good. And so why did this get faster as we increased the heap? Java likes memory. It likes big heaps. And the bigger that heap is, the more lazy it can be about actually kicking off incremental GCs. So the less incremental GCs you do, the less time you spend in GCs. Pretty obvious, right? Large enough heap and a short enough run, you may never GC. So using lots of memory might be exactly what you want to do to get good performance. All right, so drawing towards the end here, we'll talk a little bit about some new users that we've got over the last year. Guilt Group, who's actually a sponsor here at RubyConf, is using JRuby for most of the, I'm not sure what portion, but I'm using it for a number of their production applications. The Oslo Gardermann Airport, I talked about this last year, we talked about this last year and it is now actually live. What they have is a JRuby-based point-of-sale terminal running on a little Linux unit using SWT for the widget set and it's the refueling system for all of the airplanes that come and go from Oslo's airport, which it's kind of terrifying that JRuby's actually involved in aircraft refueling now, but it works great and they were very rigid in their testing and it's live, I think they're gonna do another revision of it this coming year. More recently we heard about the Allen Telescope arrays actually using JRuby to script all of the operations of the radio telescopes up at UC Berkeley and the great quote that we got from them was, if we do find any intelligent life out there, JRuby will have helped to find it. Awesome, awesome. Pawns.eu is a very large European dictionary, online dictionary, they actually moved to JRuby because they wanted to be able to have the entire dictionary set in memory, which was multiple gigabytes of memory and the only way they could do that was to run say a 64-bit JVM with JRuby and then it all just runs in memory and it runs great for them. And of course we got lots and lots of Rails deployments since last year. So some future stuff for JRuby. We're gonna continue cleaning up the known perf issues we have. We've actually got plans to do a JRuby summit up at Tom's Cabin to clean up some block dispatch performance issues. We're gonna work on a new optimizing compiler. The current compiler is pretty much a dumb translation to JVM bytecode and it gets us a good boost of performance but there's a lot more we could do. For example, we don't actually do any runtime profiling of any Ruby code. If we started to do that, we could inline all sorts of stuff, eliminate Ruby math overhead, all that sort of cool stuff. And we have Sub-Brahamian Sastri who actually did his PhD work on an optimizing compiler for Java which is under the covers quite a dynamic language. So we have a real compiler guy now. That's awesome. Gonna try and get Java integration parity with all the other JVM languages, especially our arch enemy Groovy. We must defeat them. But, you know, Scala and Clojure and any of the other JVM languages, we wanna make sure that we are at least as cleanly integrated into the JVM and the Java platform as any of those languages are. Looking forward to Java 7 and future versions of the JVM, Java 7 is going to have fast dynamic invocation support and we've already started to add this into JRuby. So the same JRuby distribution, the same binaries, you'll be able to ship and run on Java 7 with Invoke Dynamic and ideally get a performance boost once they get all the dynamic optimizations put in place. And that's coming along well. There's also work going on to add tail calls, continuations, there's a proposal for doing fixed nums which allows us lightweight boxed numerics, all sorts of stuff that's going on. And again, we don't have to do any of it. Other people implement all this stuff and we just take advantage of it. Okay, and of course, Engine Yard, we're really excited to have JRuby as an option in Engine Yard Cloud very soon and having official formal JRuby support offerings. I think we go till two here, right? So I'm gonna do this really quick. What I have here is a piece of code that actually shows some of the new Java integration features to call out to hibernate. Now the interesting bit is actually this model class which is just a normal Ruby class. It extends hibernate model. It has an ID that's a long, a title that's a string and a date that is a date object. And then there's this little hibernate bang call that turns it into an actual hibernate model object. And then our little script here, when we do store, it'll store an event, and we do list, it'll list one. So let's go back here to the hibernate demo. Okay, so I'm gonna run event log and first we'll do a store of RubyConf. And hibernate is a lot of logging out, but so I'm gonna pipe that away for now. All right, so JRuby event log and this actually boots up hibernate, does all of the internal stuff for hibernate stuff, and it's stored it. Stored it in the local, it's actually using an hsql database so it's just on the disk here. And then if I run this to list them, you'll see that we are actually, we've got full two-way persistence with hibernate just from Ruby code. And this is an excellent way to get Ruby into an existing organization because it's by far the most commonly used ORM and Java organizations. Okay, we're wrapping up here. So here's how you can get started. It's really easy, easiest Ruby installation ever. You can either use RBM or PIC or one of the little Ruby installers or just go download from www.jruby.org. I said I mentioned we have an installer for Windows, but download the tar ball and unpack it and that's it, you're done. It'll run, you'll need the JVM but almost everybody here probably already has a JVM on their system that'll work great with it. And then join the mailing list, join our RC channel, JRuby on FreeNode. Let us know what you think and talk to us about it. And we would love for everyone to help spread the word about how great Ruby is and how much better it makes doing development on the Java platform. There's the links and I think we may have a little bit of time for a couple of questions. So questions anyone, anyone at all, we answered all. Yes. You mentioned something about JRuby on the iPhone. Did I hear that correctly? No, I was mentioning, there's a lot of people talking about Mac Ruby on the iPhone. Ideally, that's probably doing to be the easiest and cleanest way if they're able to get it on the iPhone. And as far as I know, Apple actually has a license agreement forbidding anyone from putting the JVM on the iPhone. Yeah. I think they have the JVM on the iPhone. Right, right. Yeah, in front here. Let's do the start time and Android with JVM. Like is it detrimental? Well, right now it's not great. There's too much code loading. So the question was about start up time on Android. It's not great. It's one of the things that needs to be improved. And generally what we're gonna wanna do with an Android-based JRuby app is probably pre-compile all of the Ruby code so that it's in Dolvix, the Dolvix VM's native format and then it'll start up faster and it'll use less memory, all that. But we'd love some help with making that stuff work and people testing stuff out. Yes, here. I'm interested in how to get the Android like get started on that. So that'd be something I didn't know. And the other thing I wanted to ask is I saw you create an NB just by inheriting from the dynamic B plus. I didn't notice whether you registered it with the JVM. I always thought you had to do it. You do. There was a line. Oh, so yeah, the question is, I saw the definition for the beam but I didn't see any code that registered the beam with the live system. And there were, there was two lines lower down that I didn't show. That just said register. It wasn't. All right. Any other questions? We've got three more minutes until two o'clock. Over here. Yes, over there. When like we've seen day rooming supported in Ingeniard, exactly. That is the question for the Ingeniard Cloud team and the support folks. We were working closely, obviously, with them to make sure that it works in both environments and the support offerings ready. I'm not really sure what the plan is currently. It's real close. It's real close to it. I think there's already beta support in the older Ingeniard products to allow you to run JRuby and fit it into the environment. And the cloud stuff is probably right behind that pretty soon. Yeah, actually we'll be using the Ingeniard cloud stuff. We'll be using the Glassfish gem, in fact. So it's probably the nicest, cleanest way to run Ruby. I think we can take one more question. One more really good question. In the back, Jay. You mentioned competing with Clojure earlier and there's now the Gemstone judge. And both of those have different implications of software transactional Ruby. Is JRD detached from the global system? OK, so the question's about Clojure and also a little bit about the Maglev Gemstone stuff and having software transactional memory. There's actually several folks that are using JRuby and Clojure to utilize Clojure's STM. The STM and Clojure is actually an API that you can call and it wouldn't be difficult to wrap it with a little bit of Ruby code. It's all just calling across Java libraries to be able to use the STM if you wanted to do that for your concurrency. As far as deeper integration of the STM into JRuby, we're pretty much what Ruby is, is kind of antithetical to doing a standard STM setup internally, but I think using it as a library would be very easy and probably a lot of fun. And I know there's some folks that have Rails apps that actually the back end is using Clojure STM to do all concurrency. It's like, yeah, I think so, guys, working on some API for STM Ruby, you can collaborate with them and because it's been out of Clojure, it would be, you know, I think it's very constant. Oh yeah, yeah, that would definitely be nice and especially if we could have a common API. We may not be able to support, so the idea was being able to share the API or use a common API. Being able to do a nice STM with the Clojure stuff at various levels of integration with Ruby would be awesome and we'd love to see it. It probably wouldn't be too difficult to actually just do it all in Ruby code. All right, so thanks very much. We'll hopefully see you at JRubyConf and we'll be here the weekend. Thank you.