 And we're going to talk about JRuby deployment and other situations on a lot of different platforms. Who are we? We've both been JRuby co-leads for about 10 years now, working full-time on JRuby for about 10 years. We currently work for Red Hat in the past. We worked at Sun Microsystems in the beginning, then at Engine Yard for a few years, and now we've kind of settled into Red Hat. We're sponsoring our work. And we enjoy the travel to conferences and hanging out with all of you and having beers with everybody around the world. So if you've got a beer to recommend, please let us know. So JRuby is JRuby, but it does a lot more than that. It's JRuby on the JVM. It has access to libraries. And we have versions that are compatible with 1.8, 1.9, and 2.3, although we're mostly focusing on the current version now, 2.3 and 2.4. Like I say, it's built on top of the Java platform. So a lot of the issues that you typically have with the JRuby application, garbage collection, threading, just straight line performance, most of those are not issues for us. JRuby almost always runs stuff faster than JRuby, sometimes a lot faster. And the other issues like garbage collectors are just generally not a problem. Plus, if you want to run five concurrent requests or 10 concurrent requests on JRuby, you pretty much have to have five or 10 JRuby instances. And maybe that's actually 10 to 20, because you'd like to have some failover if something blows up. Well, with JRuby, you can actually take that application and run it all in one JRuby process on one instance and get all of the throughput and all the performance that you'd get from dozens of JRuby implementations at the same time. This is a benchmark that we used years ago. It's still very much valid. So this is comparing Ruby 2.0 with a Ruby version of a red-black tree implementation, two and a half seconds to run this benchmark. Just builds a tree, manipulates its walks a few times. Ruby has a C extension, and as Chris Seaton had in his talk, this is typically the way that people would get performance out of a Ruby application. Take the parts that are hot and that are running slowly, turn it into C code and then plug it into your Ruby application. And it does make a big difference, about five times faster here for JRuby. The real magic though is JRuby running the exact same Ruby implementation of the red-black tree on top of the JVM, using the JVM's optimizations and some of our own internal ones. We can be almost twice as fast as CRuby with the C extension. So there's really not a reason that we have to call back on C extensions as we get more of these optimizing Ruby implementations, like JRuby, JRuby Truffle, and so on. All right, Tom, talk about status a little bit. Yeah, so we just put out JRuby 9.16 on Wednesday. In fact, it was a little bit conference-driven in that we put it out in Ohio or from Minnesota. There is really no theme for this point release. I think we had more socket fixes than anything, but just lots and lots of random small things reported from the last release. We support two branches on JRuby, our legacy JRuby 1.7 branch, and then Master, which tracks the latest version of JRuby 9.000. On JRuby 1.7, we support 1.8 and 1.9. And for Master, we track the latest version of Ruby 2 that we support. And so towards the end of this year, we'll probably put out another point release. And with any luck, we're going to put out Ruby 2.4 support at the same time that C Ruby puts out Ruby 2.4 support. So I think we're being aggressive, but I think we can do it. And on the 1.7 branch, we're planning on killing maintenance on this at the end of the year. But we'll probably have another point release. So one really interesting problem that we saw is that in Ruby 2.4, Fixnum and Bignum have been alias to integer. There's been this unification. If we actually go and look at this code snippet here, you'll frequently see people do kind of with Fixnum. In actuality, we've always wanted to do kind of with integer, and we've all just picked Fixnum for whatever reason. So for most people's code, this will cause no breakage at all. There's only one use case where things will break in 2.4, and that's when the precision matters. You're using this checked because you only can handle a 64-bit value. In that case, we don't expect a lot of problems because frameworks like Rails have already updated for this, so it'll work in 2.3 and 2.4. And we think that any other database adapter that might care will also update for this, so we think people can just update to JRuby 9.2 when it comes out without having to change their apps. But if we do come into a problem like that, we can always create a maintenance branch, but we don't want to. So this is probably the scariest change in 2.4 for me, just because we're taking two classes and they disappear, basically, from the system and turn into one other one. So has anybody run into any issues with this? Is anybody trying the 2.4 stuff? Besides Aaron? Besides Aaron? Yeah, I'm curious what will happen. I'm curious if we'll actually see anything. I suspect probably not much will be a problem, but it'll be interesting. So on the other side of things, we want to kill JRuby 1.7. We don't want to maintain it now. People who are running 1.9 applications increasingly are having problems with gems because 2.0 has been out for a long time, so it's time. But if for some reason you can't actually update to JRuby 9000, we'd really like to hear why we'll try to make you transition in the most least painful way. So talk to us. If you search for JRuby 1.7 EOL, you will find a GitHub issue where we're trying to aggregate all the other problems people are having, things that keep them from upgrading to 9000. And so JRuby 9.2 release will be predicated on basically all of those things being resolved so that anybody stuck on 1.7 now can upgrade. So a major bonus feature of JRuby is that we can interact with the Java ecosystem. The biggest feature is that we can script Java, so we can take a Java class and Java objects and just pretend that they're Ruby objects. There's no compilation. There's no type declarations. You just pretend it's Ruby. And we provide some additional shortcuts, which I'll show you to make that disparity between Java and Ruby and how we use those feel more Ruby-like. Why? There's a whole bunch of Java libraries that exist that don't exist in the Ruby space, like you consider an e-commerce API that only has Java bindings. For the CRuby land, then you'd have to write a little server and make it restful so that CRuby can talk to it. And JRuby can just call those APIs directly. And there might just be something missing. Java libraries are as old as dirt, so if you wanna go and do something with PDF, it's gonna have every weird option for PDF that you'd want. As an example, I'm selfishly gonna use plug-in. As a library, I wrote that allows you to write plug-ins using a Ruby syntax. And it's a great use case for scripting Java because Minecraft's written in Java. So I wrote a little plug-in here called Egg Madness. You can set how many things you want to come out of an egg and let's get this thing rolling. Oh, he's gonna put the sound on it. So every time I throw an egg, 120 chickens are coming out and I don't know why I decided to keep throwing more eggs. And I kinda like this world. Once you have like a few thousand chickens in one area, things don't work so well. But, here I just went and wrote this up in using the Java APIs. You don't have to understand Java but I'm just gonna kinda walk through what it does. We define a class called chickens. It includes this Java interface called listener which is just telling Java that it wants to listen to events. And then I'm registering one event which is a player egg throw event. It's for when you throw that egg. I'm modifying the event to make sure that it always hatches something and it's gonna give 120 of those. And then just for a bonus at the bottom, I'm printing a message back to the player. So if I go and just rewrite this using Ruby pretending that Java's Ruby, there's a blank slide. Here we have class chickens. It includes that interface. Kind of ignore that add method annotation. We have a bunch of magic that we add in those few places where Java and Ruby don't play nicely together but that's what that's for. But then we define that one method to handle that event. You can see again we're setting hatching to true and we're doing the rest of the stuff we saw in the last slide. So this is already looking pretty Ruby-like but there's a few things that we don't do in Ruby. One thing is we don't have setters so we allow a syntactical shortcut so that set hatching now becomes hatching equals true. Things are looking better. Likewise with getters, you can reduce get player to just player and then player.send message. Well, we don't like camel case methods in Ruby so we actually have a shortcut for that as well. And so now we have something that pretty much looks like an idiomatic Ruby class. Of course as Rubyists we like to improve on that. You constantly work with events in Minecraft so in my library I just made an event method where I specify the event I wanna handle and I pass a block to it and that block is what the event gets. So one interesting thing is it actually generates that class for you on the fly because Ruby allows you to do that and you can't do that stuff in Java but the block itself, that's actually a Java object. That E is a Java object but you would never know. And that's pretty cool because that is essentially the entire plugin right there. You throw that into the plugin stuff and load it up and so obviously a lot easier than writing plugins in Java. Okay, so I'm gonna talk a little bit about where we stand on Rails 5 support. Maybe taking a step back. JRuby has supported Rails for years. I think we first ran it successfully in 2006. It was very, very early days for it but we've run Rails in some capacity for 10 years and that's gotten better and better. There are hundreds, maybe thousands of applications out there running Rails on JRuby, scaling it well, all that stuff. Rails 5, we had a lot of work to do on JRuby 9000 so we didn't get a lot of time to work on Rails 5 support, making sure all the libraries worked. So we took a little bit of a step back. The answer is that Rails 5 today works mostly. You can take the existing JRuby database adapters, plug them into a Rails app and most things will generally work but ActiveRecord is the spotiest part. Most of Rails is just pure Ruby, doesn't really interact with native libraries and whatnot. That stuff's all fine. So if you're using Rails and not using ActiveRecord, Rails 5 on JRuby probably is just fine for you. ActiveRecord has had a lot of changes, has improved over the years and our library for it, ActiveRecord JDBC, which uses the Java database libraries, has not been keeping track as well as we'd like. So we're working on this now. The goal is to basically be 100% on all Rails tests and get into Rails CI and everything else. So the old adapters, I mentioned they had some problems. We have supported lots of databases in our adapter. Obviously the big three SQLite, MySQL, Postgres isn't on here, are in there and work very well. We've also had Oracle support, Microsoft SQL support, a bunch of embedded Java databases, DB2, Firebird, a whole bunch of weird databases, mostly because JDBC gives us such a nice API for wrapping these up. If there is a Java database driver for it, you can use it in Rails. Definitely doesn't work that way in CRuby. Somebody's gotta write a new C extension, get the wiring into ActiveRecord. Most of the time you can pick any database off the shelf, even the weirdest ones and run them with JRuby. And so that's all great but that's a lot of code to maintain. And so we're taking a step back to reevaluate how many of those databases we wanna support personally. The other thing is that this code base has been around a long time, as I said, and the goal originally was that you could install ActiveRecord JDBC version 1.x and it would work on multiple Rails versions, five, four, three. I think we kinda start cutting it off after two versions back, something like that. But then that means we've got a code base that has is it Rails 4, is it Rails 5? Just nasty, messy code. And when the internal APIs of how to integrate an adapter in Rails change, we've got a lot more work. How do we actually support two completely different APIs in our database library? That doesn't make sense. There's another dimension too. On the internal Java side, there's different versions of JDBC and we actually have a bunch of conditionals for that. Yes, yes, so it was just a mess. It was trying to do too much in one box. And then as a result, we also had lots of duplication. We were redoing a lot of work that had already been done in Rails, often wrong. We weren't doing it the way that Rails did it. And then trying to integrate those things back together, just a mess. So we figured with Rails 5, it's time to reboot that library and just do it the right way. So the new adapters, the new SQLite adapter is an example of the reduction here. Of the code we have in the new ActiveRecord JDBC, 75% of it is the same exact code that's in Rails. And for Rails 5.1, we wanna try to push that out of the system and just use the Rails version. Similar ratios probably will come along for MySQL and Postgres. We will not have any version checks in the code base. If you're running Rails 5, Rails 5.1, 5.2, you will install ActiveRecord JDBC 5, 5.1, 5.2 that'll have support for that version of Rails and we will maintain those other versions about as long as Rails maintains their dot releases of Rails. We will only match the first two digits so you'll at least know what version of Rails it ties to. The other two we'll use for our minor fix updates and our security updates that are specific to JRuby. And then, like I said, in 5.1, we'd like to work with Rails, folks, to get more of this code that we're basically copying back into Rails. It's not gonna be a big challenge. Basically, we take a look at the SQLite adapter, the MySQL adapter, all of the stuff that is not specific to JRuby or JDBC, we can pull out into a module, we both mix it in, done deal. So it should be easy enough for us to reduce the maintenance cost on our side substantially by just reusing the Rails stuff and potentially, if it's small enough, we may even be able to integrate it with Rails directly and just maintain it as a family together. So the roadmap on this, SQLite 3, we've been working on it for the past couple of weeks. Mostly, Tom has been working on it. It's working extremely well now. It's nearly 100% on running ActiveRecord tests which is amazing. And like I say, 75% of the code that's in there, we're not even gonna maintain. We just maintain a low-level API that maps JDBC into what Rails expects. MySQL and Postgres, now that we've got the pattern for how the new adapters should be written, should go very quickly and should be able to use a similar ratio of code from Rails with a small amount of integration code on our side. We have some Oracle support, specifically to Oracle in our library. I think we're just gonna drop that because anybody that runs Oracle on Ruby ends up using the Oracle Enhanced adapters which are maintained. They work on both CRuby and JRuby very well and they're much more complete. So if you're using Oracle on our stuff, look at Oracle Enhanced because we're not gonna continue to support that in the future. The other databases will do an evaluation. There are a lot of folks that run JRuby with Microsoft SQL Server because it is still pretty painful to get it up and going with CRuby. DB2, I don't even know what the support story is on the Ruby side as far as drivers. And then of course, lots of the other databases don't even have an equivalent on CRuby. So if you wanna run it in memory database or an embedded Java database, we may keep those around. But we need to reduce our maintenance cost on this too. So if you're running anything that's a weird database and you wanna see support for it on JRuby, let us know. This is our status right now. I ran these just yesterday. And as you can see, the vast majority of things are now passing. The two that have a few concerning failures that we gotta fix, active support, there's some date stuff in there. I think mostly it's a bunch of things that are the way we handle dates are slightly different. And then some just oddities in how Nokogiri XML works, the structure of the nodes, the structure of the XML that it produces and so on. So slight differences, probably not a big deal. The active record stuff, we got a few failures there, but again, looking really good at this point. Most of the other ones are pretty solid. I haven't looked at the action viewer, action cable failures, but I don't expect them to be much more complicated than fixing dates and whatnot. So we're at a 99.57% of all Rails tests with running on SQLite pass on JRuby at this point. We wanna get to 100% across the board. We're very close. These two are the biggest ones that are gonna be focused on in the near term to get that to 100%. But this is by far the best we've ever done on Rails 5. And it's close to the best we've done on Rails period. I think all the tests might have been green some years ago, but like I say, the database driver was not really maintained. If you add those up, that's six nines. Yeah, there you go. Six nines support for Rails. So if you wanna try this out, we have pushed some preview adapters for at least SQLite 3. The other ones, my SQL Postgres may or may not work right now. But you can test it out. Gem install, pre, pull it in, start playing with it in your Rails app. If you're generating a new application, you can generate it without, skip the bundle step, go in, tweak the gem file so it points at the pre-release SQLite gem, and then do the bundle, and it should be up and going. All right, so now Rails is one of the ways we do applications. There's lots of other frameworks and servers and whatnot. So the big questions that we always seem to get is how do I actually put JRuby into production? What's the deployment story? So we'll walk through a little bit of this. So there's really two ways, two worlds of deploying JRuby. We live in the nexus between the Java world and the Ruby world. For folks here that I would expect are pretty much doing the Ruby way of doing web development and deployment. Almost all of this stuff still works. You're probably using Puma or a similar server. Most of the basic Ruby web servers work fine on JRuby. There's also one that we at Red Hat have built called TorqueBox, which provides both a small run on the command line server and an entire server environment with messaging and queues and whatnot all in the box. Either way, you can use TorqueBox as well. There are also some additional frameworks that are specific to JRuby like Rat Pack that can use JVM frameworks, JVM web servers to do various cool things like web sockets and so on. The most deploying scenarios work. Capistrano people have been using on JRuby for years. Pretty much everything else should work just fine. Deployment is usually not a complicated part on that end of things. And then there are actually some tools for taking a JRuby application, including Rails, including all of your external libraries, and turning it into a single executable file. So you can take this, even if you want, you can pre-compile all the code. You don't have to, but dump it all into this one archive, send it anywhere that has a JVM, no additional dependencies required to install, you just run the jar, you've got your Rails application up in production. And lots of people just absolutely love this for deployment. You don't have to install a thing on the server. This file gets in there, it starts the applications running. Impossible to do with CRuby right now. So the other side, the more Java style, if you're in a Java organization or you're trying to get your Ruby application into a Java world, I mentioned TorqueBox, which is a full stack environment. Don't have to worry about all those other little services hanging around. Warbler is a way to turn a JRuby application into what's called a war file for a Java environment. A war file is just a packaged up zip with some descriptors. You throw it into an application server, it unpacks it, launches it, and lets you manage it and maintain it and all that. So that all works with JRuby as well. So whether you're doing the Ruby side of things or the Java side of things, as far as the server deployments that you do, JRuby has an answer for it. We had our friend Joe, who was written an excellent book on JRuby deployment, give us a couple examples. Here is Docker deployment. Right now we'd kind of recommend that you start with a base of whatever JDK you wanna run, the JVM version, and then just a few bits and pieces to actually pull JRuby down and use it within that Docker environment. We are talking about having an officially blessed Docker image out there, but we don't know what the maintenance is. There's already a couple of good ones that people have pushed, so that's still kind of an open question. If you have any thoughts on that, feel free to ping us. And then, you know, Docker push and you've got a JRuby environment running. I mentioned the executable jar stuff. Here's two ways you can do it. Warble with a war file that turns it into the web application and TorqueBox jar. These are essentially just run this command inside your application. It will read in the gem file. It'll pull in JRuby, package it all up in one file, and you've got it. Ship it. You're ready to go. Heroku also has in their gem a deploying to a jar. They've got another tool that actually builds this up really nice. And interestingly, the warble war case, the jetty case, that war file can be deployed into a Java application server or just run directly. And it includes a little web server inside it. So you don't even have to have a server application to plug it into. You can just take this and throw it anywhere there's a JVM. And then of course, if you're doing Heroku, Heroku has great support for JRuby. Just push your application. It should work. And there's lots of fine folks over there that are making sure that continues to run. And most of the other cloud environments have something like this. I think most people probably in the other clouds would be using something Docker based. So that's kind of covered too. You'll see later that getting JRuby up and running without any of these things is still also very easy. Just a quick note on some of the other services your applications might depend on. The vast majority of services like Memcache, Redis, and so on have libraries that work in either CRuby or JRuby. For example, the 0MQ library that most people use is FFI based, in fact. And it works just great on JRuby and MRI exact same code base. Pretty much all of these services have other JVM libraries too. So if you want a higher performance Memcache client or if you want to have fast HTTP client for RESTful services, there's probably a Java library out there that you can use. And as Tom showed, you can just pull it in and call it like it's a Ruby library. The lower level database support stuff, we use a library called JDBC in the Java environment which has the basics of querying and updating but low level, postgres specific things are not necessarily there. Or low level MySQL things are not necessarily there. So this is still kind of an open question like how to support these. But almost all of those things are available through some other JVM library. You may not be able to go through the standard JDBC interface, but there is a postgres fancy stuff library that you can pull in. And then again, I mentioned TorqueBox but it is really cool to just say, here's my application, I need messaging, I need queues, I need background jobs, go. And it just sets everything up for you across the board. It all integrates well, it clusters, it fails over, all that stuff. And all you have to do is run TorqueBox deploy and you've got your application. I mentioned the book that Joe wrote, excellent book, goes through a whole bunch of these different options on how to get JVB up and going in lots of different environments and different types of applications. So definitely check this out, this is a great book. All right, Becky. All right, let's write some GUIs. JRBFX is a gem that we've written. It's built on top of the Java FX library. Java FX is an awesome GUI library. It's got pretty much every control that you would normally think of. And if it doesn't, it has good facilities for making your own custom controls. It has a really good shape support so you can make whatever shape you want. Of course, they have all the built-in shapes you'd expect. And then you can go and add nice strokes where you can have the stroke rounded or sharp. And you can fill it with anything. I just showed gradients here, but it could be filled with images. It could be composited together with other stuff. It's hardware accelerated, so when you actually look at the CPU for this example, which I won't point out, but you'll see that it's basically using no CPU because it's running on the graphics side of things. There's style sheets, and I apologize. This is the shittiest slide. But it was the only example. I saw two side-by-side, fairly complicated GUIs. So I'll just point out, on the right, that's this Aqua FX project that mimics Mac OS and how it looks. But this is sort of the only downside for Java FX for me is that it only ships one UI look and feel, and otherwise you have to theme it yourself. But there are external libraries that allow you to theme. And the controls are quite nice, so I'm not too bothered by it. And I'd say this is almost not even a disadvantage with so many web applications that are essentially the same interface across all systems now. Yeah, that's true. It's really not that big a deal. People know that if it says click me, it's a button, and if it's a text field, you type text into it. So you can theme it, but it looks pretty nice without it, and you don't need to. Yeah, I agree. So it's portable, so you go and bundle up your Java FX or JRuby FX application that's gonna run everywhere, which is a big win compared to other Ruby GUI tool kits. Right, again, just like with the deployment of a server application, you can take your whole JRuby FX application, throw it in a jar, and anywhere there's JDK8, you can run it, and you'll have a GUI, just like that. Nothing to compile, nothing to install additional. So there's two ways to actually work with JRuby FX. One is through our DSL, and the second is through FXML. Yeah, I said it. But you guys will all love XML by the end of this talk. But let's talk about the DSL. It's a fairly traditional builder DSL that's written on top of Method Missing and InstancyVal, so it has all the words that you would expect in using that sort of DSL. However, it makes really pretty looking DSL-y graphic rendering. So if we look at this analog clock example, we have to go and set up this path to go and fill in the black minute hand, and you don't have to follow the four things that are inside this path, but we construct a path object. This, again, is a Java object that we're constructing, and then the four things inside there are getting added as children to it. So it's very clean looking, and I'll show you some more snippets in a second, but I have to go on a little detour. I made a esoteric language implementation of the PYAT language called RPYAT, and I want to show you the debugger, but I can't show you the debugger without actually explaining the language, so I apologize. It's named after this guy, PYAT-Mond, and he's known for these graphics or art on the right side. I think we've all seen this. It's an image-based language, just like Smul, not like SmulTalk. It's literally an image. This PNG file, if you execute it, will print PYAT to your screen. It's stack-based. It's based on coddles or codles. N by N pixels makes up a single coddle, so this is a 10 by 10 coddle program. Coddles are grouped in light colors. So in the upper left-hand corner, we have a three by three coddle group. Execution of PYAT is moving from one group to the next group, and in order to figure out which way to go, you have to have a direction pointer as a runtime state. Initially, that's pointing right, so as long as it's going right, we go from one group to the next group, just keep going right, but of course, that direction pointer can change, so it's a two-dimensional language. There's also another piece of runtime state called a coddle chooser, which is either set to left or right. So these two things combine together. When you're in your current group, you wanna go to the next group, so you go to the furthest edge using the direction pointer of the current group, and then you look at the coddle chooser and then either use the leftmost or rightmost point to go to the next group. Hopefully that was clear. But I'll reinforce it, but wait, there's more. Direction pointer's right, coddle chooser's left, and we're in that normal blue square. We're gonna move into the dark blue square at A, but if the coddle chooser had been right, we would have moved in at B. There's six colors, and those six colors have three different lightness levels. As we move from one group to the next group, then we can look up in this table what sort of operation we should do. So we have stack operations, we've got math, we've got comparators, input and output, and then pointer and switch to make it really screwy so we can change the direction pointer or coddle chooser. All right, so now we get to show you the application, which is gonna be one of these. Ah, good guess. So here's a program I wrote and pie it that counts down from whatever number you input. So if we step in the first transition, we hit N in operation, which is a numeric input. I just echo three to it. So you'll see that three's on the stack. You can see the arrow progressing as I step. And now that was a pretty big group. It slid all the way off and went off the image. When you actually run off the image or hit something that's black, it starts alternating the coddle chooser and the direction pointer around until it can find a place to go again. So we'll continue, oh wait, no, let's set a break point. Then we resume. And you'll see that it kind of bounced around in that group until it could figure out it could go down that right side. You'll notice now that the stack contains two. That was all the operations I had to do to subtract one from the stack. So we'll run it again. You'll see that thing bouncing around, figuring out where to go. Goes back again. We're back at this pointer operation and the stack's one. What could happen? We go around again because we have to go to zero. And now we're at zero. The direction pointer doesn't change because it's zero. So we bounced around on that little yellow cul-de-sac and it did it eight times. Couldn't figure out where to go as to the program ended. And apparently they debugger along with it. Yeah, I should fix that. I just have like system.exe in there or kernel.exe. So here's just a little snippet from there. Using the DSL. So for each codle in the image, I just create a rectangle shape. I specify where it is and how big it is and then I can set these properties, like what color it's filled with, the stroke width inside the rectangle itself. I add that it's the style class codle. So now I have an external style sheet. I can go and change how it looks. And I registered a mouse click handler that allows me to go and toggle the break point on and off. So pretty cool. But we're gonna go really cool now and talk about FXML. FXML is a description of the layout of your code. It's essentially your view and it's written in XML. The good thing though is you don't actually have to write XML or ever look at the file. How people in Java FX and JRuby FX use FXML as they use a GUI builder, which can read and write that. The behavior that your applications are written in is just gonna be in Ruby and a controller or multiple controllers. And it's kinda nice because it forces a separation between your view and your behavior. So I didn't show this, but I recently added that feature to list the operations on the right hand side. And the layout is surprisingly hard. Any GUI toolkit that relies on layouts is just tough to get right from a programmer level, but it's pretty easy from a tool. Here's an example of a commercial product based on JRuby FX called Breakman Pro. Anyone uses it here. But this uses JRuby FX and FXML and arguably this is a very sophisticated UI and it looks very nice. So I'm gonna pop out into Scene Builder. We'll see how well this goes. I'll start a new session here. On the left side we have a palette. Let's add a container here. Border pane. And now let's look at the controls. We'll add a vertical slider. We'll add that to the right side. This is kind of a novel layout system. We'll go and add some tick marks. Put the numbers on there. You can see you can customize a whole bunch of stuff. In layout you can easily do stuff like I'm gonna add 20 padding around it on all sides. You can see it just kinda spread out. And down on the code thing we're gonna go and assign this a name slider so that the controller knows how to access it. And at any point if we wanted to handle a very specific event like when drag stopped moving cause we were trying to drag the slider or something like that, we could go and put in a method name and then that method would get invoked on your controller. I mentioned you could have custom controls. So this is a gauge from the Medusa gauge set I guess you'd call it. And it's pretty awesome. I'm just gonna show you the level of customization that Java FX provides. And this guy spent a ton of time making every possible type of gauge you could imagine. Oh here, I wanna go to LCD. I could do this all day. But let's make it blue. So that's pretty neat. Okay so at this point you'd go and save it off and generate an XML file. I'll show you what this looks like. I laid this out a little differently but in my demo I tied these together. Wee, okay so let's go back. So here's the XML, you never have to look at it but I'm showing it anyways. Here's the controller. We include that it's JRubyFX controller. That gives us the XML method which allows us to load that XML I just showed you. And then in the initializer we just register a property handler so whenever the slider changes we just set that value to the gauge on the left. Very simple example but it is really easy to work with. So for very small programs the DSL's okay and if it's dynamic you have to. You can't have dynamic XML but for anything a reasonable size you just use FXML and you can mix and match. And I think JRubyFX is the only game in town for Ruby right now for GUI. I think Shoes shows promise but it shows promise. All right so last section here. So JRuby runs on the JVM and of course the JVM runs everywhere and so we are also looking into more JRuby use on embedded platforms. Embedded platforms have gone a long way from running with 64K of RAM. We've got systems that have 512 meg, a gig or more that are still this big like this Raspberry Pi here has a gig of memory on it and can run any JRuby application just fine. So I mentioned JVMs exist for all these platforms. ARM is obviously a very important one so there's a couple different options even for what JVM you wanna use. They have varying levels of optimization. On 32 bit ARM there are challenges to jitting JVM code down to the fastest possible stuff plus there's some closed source jits that we don't have access to. 64 bit ARM is generally better these days as far as optimizing JVM code. JV runs very well on either version though and Raspberry Pi actually comes with JDK8 in the box. You don't even have to install anything so we'll walk through what the rest of this is to get JRuby up and going. So JRuby on ARM like I said joins on JVM and it works well. All of our native support should work. We have the library that can call out to FFI that can use native C functions and whatnot. Right now there is a minor bug in 9.16 where the native support doesn't load properly. We'll get that patched up for the next release though. And then all of the stuff that we've shown here the Rails stuff, the deployment, the GUI stuff, the Java FX, everything will work exactly the same way on a Raspberry Pi. So if you wanna have a little embedded environment with a GUI and toss it out to somebody it's very easy to do it and anybody else can take the code and just run it on their system. I was gonna show this live but we had some video problems and we're running out of time. So we're falling back on these slides. So step one of this, you've got JVM on there. You've got an environment running on the Raspberry Pi Raspberry and set up. So pull down JRuby, you can do this via RVM or WGet or just go and download it from our site. Just grab the tar ball. Step two unpack it and you know obviously if you wanna put it in path that's a good way to go. So we unpack our JRuby tar ball, put it in environment and we've got JRuby running on the Raspberry Pi and that's all there is to it really. There is no step three for this. But let's actually see what this looks like in practice. So here we have Raspberry Pi terminal with JRuby running and it works just like IRB on any other system would work. We've got all access to the same constants, all the same functions and then even cooler we still have access to all of those Java GUI libraries. So in this case I'm just using Swing which is kind of going away. We could run Java FX, we could run any of the other stuff that's on the JVM and it will pretty much just work exactly the same way. And then even cooler all of the eventing stuff like Tom showed we can write a button.add action listener there at the bottom and change the text of the button and we click it and then it works. So it's all the same code that you would write for a desktop environment can run exactly the same way on Raspberry Pi. Like I thought there would be more to this section when we came up with this talk but it's really just, it does exactly the same thing. Like there's no problems really. You pull it onto an embed environment, runs the same way as it does on your desktop or your server. So that's all really cool and we're really happy about that. So the few caveats here like I said the native support doesn't load just yet so if you try to do this with 9.16 let me know and there's just a couple tweaks I can give you to get it up and going. We'll have that fixed in the next month or two for 9.17. It does use more memory than CRuby as the JVM would typically do on any platform. This example that brought up that GUI was about 70 meg of reserved memory. It can be choked down significantly smaller than that. The embedded JDKs do a little bit better job of keeping the memory small but it will be more. The upside though is that you only need one of these to run a cluster of something or a bunch of little services on a Raspberry Pi that you've got somewhere in your internet of crap. And so it really can scale up just fine and again these devices now have more and more memory. I've got a one plus three in my pocket that has six gig of memory. The next generations of phone are gonna have eight so it's really not that big of an issue anymore. And as more and more 64 bit ARM comes out we'll see performance continue to improve for JRuby on embedded. And I guess that's all we have for today. So we're up for some questions. I'll try to do a screencast of the Raspberry Pi actually running JDBC so you can see that I'm not a liar. Yeah, right here. I've been chair, so the question is we have a 1.3 branch which is what the current release is of an active record JDBC is released on and then we have a Rails 5 branch but that was branched off of 1.3. There's additionally the master branch which has a bunch of other changes on it. I've been chairy picking some of those commits to Rails 5 when they make sense but someone needs to go back and review what's made it there. A lot of the changes that are on master were intended, CARES was gonna do cleanup and go about Rails 5 a different way than we ended up going but a lot of those changes are nice so we should try to integrate them into Rails 5 branch. And bringing back the 75% thing that most of our code is essentially just what's in Rails now, getting this essentially reboot of active record JDBC working at 99.5% passing within just a few weeks was phenomenal. Like it took us years to get to that point with the old code base and if there are fixes that need to come along the surface area of what we need to maintain is now so much smaller it's really just going to be any fixes that came in for that wrapper around JDBC. All the other stuff is just what Rails does. And CARES did an amazing job of transitioning the internal JDBC code to work for Rails 5 before long before Rails 5 came out so we didn't have to do as much work as I thought we're gonna end up it just it worked a lot better than we expected. Information on TorqueBox 4, yes it's still out there and it's in a beta form right now. So for those that aren't familiar with TorqueBox TorqueBox 3 is much more of a monolithic environment like a typical Java application server. You start this thing up and it's a big server in the background that's running and you throw applications at it. TorqueBox 4 decouples all of that so you can say okay I just want a server in front and a queue over here and that's it for my application only those two things will boot up so it's a much nicer modularized version of TorqueBox. Sadly the folks that work on TorqueBox at Red Hat have been doing other projects and haven't had a lot of time to get back to this so TorqueBox 4 has been kind of in a permanent beta right now but anybody that's interested in this stuff or would like to have that sort of full stack server out there released Ben the guy who works on TorqueBox is still interested and wants to do this it's just a matter of interest from the community. Maybe some tweets of encouragement. Yeah absolutely tweet to be browning and tell him you want to TorqueBox 4. Well so I don't know anything about ActionCable but 99% of the tests pass so I don't know if the last 1% is gonna be a problem or as difficult but I suspect that most of the stuff is just gonna work and so now ActionCable is that the event machine dependency that comes in? Event machine miraculously has continued to work on JRuby even though we've never maintained it ourselves someone else is doing that work but it's in there and the stuff passes so I assume it's still functioning pretty well. Sure so comparison with Groovy and Grails I won't bother with the language comparison because that's a religious discussion. The framework itself Grails it's a great framework it's very JVM Java ecosystem centric it's very much wrapped up in spring and the way that you deploy typical large Java applications and so if that's the world you live in deployment-wise it's probably gonna be very similar. Integration-wise Groovy does integrate a little bit more tightly with Java but it also has a lot of the warts of Java because it's intended to be Java plus plus basically a superset of Java whereas we're not necessarily tied down to that there's a lot of things that Ruby does in my opinion better than Groovy as far as building applications. And there's a huge difference Grails doesn't have the Rails community or any of the gems that come along with it. Right I mean the Rails community is easily a hundred times larger than the Grails community and that makes a huge difference. Like the Java ecosystems of old pretty much anything you wanna do on Rails Ruby has probably written three versions of it whereas on the Grails side there may be one Groovy library or you'll have to just fall back on Java. But I mean again, JRuby gives you a lot of that benefit that you would have with Grails without having to sacrifice Ruby. So if you like using Ruby and like using Ruby frameworks you can have all that and do everything that Grails can with Java integration and JVM stuff. It feels really aesthetic. Like some of the people that I know that really like Groovy, they can't explain it to me and I can't understand it. Yeah one more I think we're almost up. Truffle, what is Truffle? So the fella down here in the light blue shirt is a great guy to talk to he's the lead of the JRuby Truffle project at Oracle Labs. So we're working with Oracle Labs and they're working within our code base to try experimentally this new framework for building languages called Truffle which has some very interesting results performance wise significant improvements on optimization. Now some really cool work with integrating Ruby and C extensions together. We're gonna see where this goes and we're continuing to work alongside them but Chris is definitely a better person to talk to you about that. If you're a time traveler, go back one hour. This is over in the next room. And Chris is presented, Chris and other folks from the Truffle team have presented JRuby Truffle and the work they're doing at many locations, many videos online. So you can check them out there too. I think that's about all the time we have. Thanks very much.