00:00:08.559
All right, while Tom is getting set up, I wanted to see how many folks here have been Java developers. Not necessarily Java developers now, but have done Java development in the past.
00:00:14.960
Yeah, the majority of you. And how many of you don't want to go back?
00:00:22.240
Yeah, there's quite a few. One of the problems we've had with JRuby is trying to push the idea that JRuby is not about Java. JRuby is about Ruby.
00:00:31.840
Unlike a lot of other dynamic language implementations for the JVM, we have taken the approach of trying to make it as compatible as possible. This allows us to run all the applications that you're used to.
00:00:38.960
Hopefully, as we go through this talk, you’ll keep in mind that this is really about making another version of Ruby that has some different characteristics but can perform all the same tasks that your beloved C implementation can do.
00:01:02.559
We're going to talk a little bit about JRuby. As I saw yesterday, pretty much everybody knows what JRuby is, so we're not going to give a lot of introduction to it.
00:01:10.240
I am Charles Nutter, and this is Tom. We both work for Sun. I opted not to wear the Sun shirt today because I tend to do that a little too much.
00:01:15.759
However, we are both engineers at Sun, obviously senior staff engineers or whatever the title is, and we've been doing Java for about ten years. But we have a lot of other experience with various other technologies. We’ve both worked with different dynamic languages on a lot of different platforms.
00:01:33.040
So we come from a fairly broad background, primarily being Java developers for the last ten years. Now our goal is to try and make Ruby a first-class language on the JVM. By 'first-class,' I mean that anything you might have done in Java before, you can now do with Ruby.
00:01:57.680
We're also trying to take what we learn from working on Ruby and make the JVM a better place for all dynamic languages. The enhancements we bring to Ruby can benefit others as well. Here’s the agenda: I'm going to try and be a little inflammatory on some of this.
00:02:23.440
This is really a talk about why JRuby over the C implementation. It's not that we recommend using JRuby for everything, but there are certain scenarios where you may want to start looking at it.
00:02:40.720
First off, you know what JRuby is. It's a Java implementation of Ruby. But it's been around for about five years.
00:02:46.560
It’s open source, available under a couple of different licenses, so you should be able to use it for whatever you want. We have a really large and growing community of contributors.
00:03:03.680
We're not the actual founders of this project; we adopted it. So, adopt open source! Yes, that’s a great way to get your name out there.
00:03:09.680
It's also fun to take over something and make it your own. We're aiming for compatibility with the current Ruby version, while also adding the features of Java.
00:03:21.520
This includes being able to call Java libraries directly and call Ruby from Java easily. There are other projects also emerging based on JRuby, like the JWC-based Active Record adapter.
00:03:32.239
So these are the overview bullets for the next few slides. A lot of people wonder why you would want to run Ruby on Java, and more specifically, why you would want to run Ruby on the JVM.
00:03:47.599
The JVM isn't necessarily just about the Java language. These are the points I’m going to cover. I’ll jump into the detailed slides here. Starting off, Ruby design issues.
00:04:05.360
There are several concerns that people have with Ruby as it scales to larger applications. The threading issue is one of the big concerns; Ruby is still completely green-threaded.
00:04:29.680
This means that if you want to be able to scale it on today's machines—most of which now have multiple cores—you need to have multiple processes running. Managing these processes becomes more difficult, and communication across processes can be troublesome.
00:04:47.840
Another problem is that if you call out to a C library and it fails to return, none of your other threads will execute. You’ll be stuck because there’s no way to yield those threads unless they know Ruby internals.
00:05:12.160
Additionally, the Ruby scheduler is what they call a time-slicing scheduler but is a strict 10-millisecond time-slicing scheduler across all platforms. If you’re running on the slowest machine possible, it means 10 milliseconds per thread. On the fastest machine, it’s still 10 milliseconds per thread.
00:05:49.039
Every major operating system now has an adaptive scheduler, which results in Ruby not scaling appropriately with multiple threads on different machines.
00:06:12.240
Ruby 1.9 fixes a lot of this, but it doesn’t allow you to run those threads in parallel. It does introduce native threading, but they all wait for a large lock.
00:06:39.840
The problem with Ruby 1.9 is that even though native threading has been implemented, not all the internal libraries are safe for multiple threads. This means you cannot guarantee the integrity of the runtime when multiple threads are running in parallel. It's partway there.
00:07:06.560
The other issue with threading in Ruby 1.9 is that there’s a desire for all extensions to continue working as much as possible. Extensions are not aware of Ruby threads, which makes them not cooperate well with the threading model.
00:07:31.360
Regarding Unicode, the situation has been bad in Ruby 1.8. When we started at Sun, we were asked about Unicode support, and many were surprised by the lack of it. The reality is that Ruby has faced issues supporting Unicode effectively.
00:07:56.960
This has been a significant issue for Ruby developers, especially in communities that require Unicode, such as European communities. It wasn’t until Ruby 1.2 that a library for multi-byte support was finally added.
00:08:26.240
Ruby 1.9 introduces support for Unicode and several other encodings, but these changes are aggressive and will break a lot of APIs. This will lead to a migration period to the new string implementation because it does not work with bytes anymore—it works with characters, and counts are in characters.
00:08:54.960
The speed issue with Ruby is that while it is fast enough for some applications, it is slower than many other implementations, which often deters developers from adopting it. Many are concerned about performance and do not want to take that hit when moving to a new language or platform.
00:09:29.680
Although some implementations in Ruby may outperform C++, they are exceptions rather than the rule. In general, there isn’t much in the pipeline for performance improvements in Ruby 1.8 as it is mostly frozen.
00:09:53.920
Most of the visible improvements are expected with Ruby 1.9, which looks good in benchmarks, but it is important to note that these benchmarks are optimized without addressing the overall performance enhancements.
00:10:11.680
Also, it's unclear if there will be a full ahead-of-time compiler or if it will just run the compilation every time it starts. We don't know whether it will implement just-in-time compilation to native code or enhance the garbage collection and memory model.
00:10:45.440
Additionally, concerns arise since Ruby 1.8 will not experience major changes until we reach Ruby 1.9, which is coming later.
00:11:10.400
Memory management in Ruby is designed simply. It is based on a stop-the-world garbage collector, which leads to application pauses as it cleans up memory. Although it’s a straightforward garbage collection method, it's not optimal for complex applications.
00:11:58.800
Changes to the memory model will likely remain unchanged in Ruby 1.9, and if Ruby becomes significantly faster, the amount of garbage created will also increase, resulting in more pauses.
00:12:46.000
Extensions are another issue, as most users have written or used extensions. The situation with Ruby's extensions, while they work well in Ruby 1.8, tends to limit Ruby's flexibility.
00:13:14.960
Changing the memory model, threading, and other things can break extensions, thus slowing down the Ruby development process. Additionally, C-based extensions often lead to crashes in the Ruby VM due to memory management issues.
00:13:53.440
The long-term advice often given is to write performance-critical tasks in C, but developers prefer writing in Ruby. The politics of getting Ruby integrated into large, slow-moving organizations also pose a challenge.
00:14:50.320
There is a legacy of Java applications that may not be compatible with Ruby, but Java's vast library ecosystem gives developers a significant choice.
00:15:34.240
We’re exploring ways to leverage existing Java libraries in the Ruby space, and we’re making Ruby work alongside Java to access its functionality.
00:16:04.320
Tom will discuss how JRuby addresses some of these issues next.
00:16:29.760
In discussing JRuby, the first point to note is that Java is natively threaded, giving us the ability to run code across all cores effectively.
00:17:01.440
All core classes are now thread-safe, allowing multiple threads to operate across multiple cores and even multiple JRuby runtimes within a single process.
00:17:38.320
This changes how you design applications, knowing that you do not have to rely on inter-process communication.
00:18:01.600
The second important feature is Unicode support—JRuby is built on top of Java's Unicode libraries, allowing full compatibility with Ruby's string functionality.
00:18:39.440
Scalability and speed are critical. We’re working hard to improve our interpreter's speed and are optimistic about achieving comparable performance to Ruby 1.8.
00:19:12.960
We support preliminary YARV innovations within JRuby, which gives us promise for performance gains.
00:19:45.440
Additionally, we’re exploring compilation to Java bytecode, supporting ahead-of-time and just-in-time modes.
00:20:15.440
More recently, we've found that simply writing clean, effective code allows the JVM's HotSpot compiler to optimize the code better.
00:20:56.640
Java’s garbage collector is one of the best in the world. We leverage that to avoid memory management concerns while enhancing performance.
00:21:31.920
Java enables developers to write Java-based rather than C-based extensions, significantly reducing the risk of crashes.
00:22:09.440
By eliminating the need for excessive code, we find that Ruby sits nicely on the JVM and makes working with Java libraries effective.
00:23:00.640
One example is a Swing application using a DSL that simplifies the complexity of Java libraries.
00:23:49.440
We can write concise, user-friendly code using JRuby, creating clear syntactical abstractions that improve usability.
00:24:13.760
This is a powerful combination as we build Ruby applications on a tailored Java platform that speaks to both languages.
00:24:50.720
This collaboration captures the strengths and compensates for the weaknesses of both languages.
00:25:23.440
Next are the developments in NetBeans, a project by colleague Tor Norby.
00:25:56.000
NetBeans is making strides by integrating Ruby capabilities, including auto-completion, error detection, and efficient code navigation.
00:26:27.680
Ideally, this editor will be a comprehensive tool for Ruby and JRuby development, thus enhancing productivity and usability.
00:27:01.120
Applications can be run concurrently, exposing Ruby developers to a world of Java integration through the editor.
00:27:34.560
When we explore benchmarks, we aim to evaluate JRuby’s performance in various aspects, thereby assessing compatibility and capability across different use cases.
00:28:06.400
There is a significant focus on performance optimization according to the rules and standards established by Ruby developers.
00:28:45.760
While there’s progress, many benchmarks still emphasize that JRuby often trails behind in speed on general patterns of performance.
00:29:16.160
There remain opportunities for refinement; JRuby's collaboration with Java libraries combines the stability of Java with the expressiveness of Ruby.
00:30:03.200
Overall, we believe that with sustained effort, JRuby will improve memory efficiency, speed, and usability in managing Java integrations.
00:30:44.000
We will continue to build on the existing Java ecosystem, including writing effective wrappers for Java interfaces that also enhance Ruby usability.
00:31:32.960
In our exploration for competitive design, we’ll continue collaborating to debug and build features that can enhance the overall JRuby experience.
00:32:03.680
We welcome continual engagement from the developer community to further evolve both languages, maximizing their potential.
00:32:39.840
Moving forward, we look toward shared objectives that optimize both Ruby and Java, ensuring a beneficial future.
00:32:58.880
Our focus will remain on advancements that enable seamless integration with Java capabilities while enhancing Ruby performance.
00:33:35.680
In conclusion, we’re excited about the prospects JRuby opens for developers and the future of Ruby on the JVM.
00:34:15.200
We’ll continuously adapt and embrace innovations within JRuby to empower developers to efficiently navigate the dynamic programming landscape.
00:35:11.280
We value questions and feedback that will further lead us towards our shared vision of elevating Ruby.
00:35:46.160
We look forward to conversations that will allow JRuby to continue thriving while staying true to its community-oriented principles.
00:36:23.040
Thank you for your time, and I encourage everyone to engage with us in our ongoing journey built on community collaboration.
00:36:47.840
Feel free to reach out with any questions about JRuby’s evolution as we move forward.
00:37:04.960
Thank you.
