00:00:03.520
All right, we all want to be on time and get to the warf, so I will run right through this. We have 68 slides, and we'll see how far we get. This is my basic information; it's kind of an amazing run that we've had working on JRuby.
00:00:14.440
I’ve been a Java developer for 20 years now, which is shocking to me, and I've been working full-time on JRuby since 2006. In a couple of years, it will have been 20 years of me working full-time on JRuby, and fully half of my career has been devoted to this project. I hope it’s useful to some people.
00:00:28.880
I work at Red Hat, which is now part of IBM. A shout out to Red Hat for sponsoring us for the last 12 years! It’s me and another developer, Tom Enebo, who are both paid full-time specifically to work on JRuby and help out with other JVM language concerns.
00:00:40.559
We've been really lucky to have a series of sponsors over the years that keep us going. So let’s get into JRuby. How many folks have ever tried JRuby for something? All right, how many have put something into production with JRuby?
00:01:01.039
A lot of the same hands, but there are still opportunities out here for many of you. JRuby is, of course, Ruby on top of the Java Virtual Machine (JVM). We like to say it's a Ruby implementation first.
00:01:14.799
Over the years, people have been afraid of anything attached to Java or the JVM. We work very hard to make the experience of JRuby feel just like regular Ruby. You have a standard Ruby installation, and we use the standard gem commands. All the things you do normally with regular Ruby should just work exactly the same on JRuby.
00:01:28.000
We are also a JVM language, so we get advantages from that ecosystem that I’ll talk about later. Generally, we expect that anything pure Ruby should just work.
00:01:34.520
We’ve done a lot of work to ensure compatibility is solid and to make sure that the experience of using JRuby matches regular Ruby. All of the same tools are going to be functional for you.
00:01:47.640
There are minor differences, like the fact that different extension APIs exist. The C extensions don't run directly on JRuby and need to be ported to Java or just use a Ruby or Java equivalent library. We also don’t support forking because we can do parallel threads.
00:02:07.119
So, we can get all of our concurrency without multiple processes and keep it inside one JVM, which can be more efficient in a lot of ways. We have thousands of production users over the years, and again, we have 17 years or more of real-world use since the first JRuby production application was deployed.
00:02:25.640
We often look at this problem trying to define what is important for a Ruby implementation. Usability is the first thing; that’s where I say we are a Ruby language first and a Ruby implementation first.
00:02:37.920
We work very hard to make sure compatibility is good, and the command lines all work the way you expect them to. We’re always working to improve startup and warmup times, but those are ongoing challenges.
00:02:49.000
There are runtime considerations necessary for JRuby. It has traditionally had trouble with garbage collection and did not have JIT (just-in-time) compilation until recently, and that’s still ongoing work. A lot of that we get for free out of the JVM.
00:03:09.599
We can deploy on many different platforms; we have mobile applications in JRuby. We've got lots of server applications, and people have built desktop apps. Being able to deploy easily in different environments is crucial.
00:03:30.480
Performance is, of course, a usual concern for Ruby applications. That doesn’t mean just straight line execution or getting one task done; rather, it means scaling efficiently across many instances, using all of the CPU cores in the system, and being efficient with memory use.
00:03:40.880
We also want it to be approachable, which is why we are always available to help people get involved with JRuby and contribute. If you have any issues while running JRuby, just assume it's our fault, and we’ll help you sort it out.
00:03:54.680
Maybe it's something you can address, or perhaps it's something that we can fix. Different applications really need different things.
00:04:07.440
We have tried to take a holistic approach with JRuby to provide the best possible version of Ruby that runs on top of the JVM. Getting started with JRuby is pretty easy; all of the Ruby installers will have support for it.
00:04:28.120
For example, you can use 'ruby install jruby' or 'rvm install jruby,' and it will pick it up. The only real requirement is that you have a JVM or a JDK on your system, which is available for pretty much every platform.
00:04:41.680
Most Linux distributions have standard packages for that. You can also go to our website and download a Windows installer, or just download the tarball and unpack it.
00:04:54.919
There’s really nothing to build because it’s written in JVM bytecode. You unpack it, put the 'bin' directory in your path, and JRuby will work from then on as long as you have a JVM handy.
00:05:20.240
Then you can try it out. Here, we switch to JRuby; we start up IRB (Interactive Ruby Shell). We can access the Java class JavaLangRuntime, and we can get the available processors and free memory.
00:05:36.720
So, we’re using Ruby now in an interactive console to call into the Java libraries. This works with the entire array of JVM and Java libraries. If there’s something cool in the JVM or if you want to integrate with Scala, Kotlin, or Closure code, you can just call it directly from Ruby in JRuby.
00:05:55.250
Regarding compatibility, JRuby 9.4 is the current major release that we’re supporting. It’s compatible with Ruby 3.1, so it’s a little bit behind Ruby, but about 98-99% of the language specs are passing. There are minor differences you might never notice, and they haven’t been reported as issues. Everything you’re going to do in Ruby is going to work just fine.
00:06:21.960
We also have an older version, JRuby 9.3, so if you have legacy applications that depend on Ruby 2.6, you could try running them on JRuby 9.3 and still get some of the scaling and benefits of the platform. We always focus on compatibility first.
00:06:49.480
Sometimes the fun work of doing performance optimization gets pushed to the side until we can really say that we are compatible with a particular release of Ruby, and then we come back around to performance.
00:07:11.240
Let me give you a little insight into how the JRuby architecture is structured. Of course, we are a JVM language, and we defer a lot of the hard problems of implementing a language runtime to the JVM.
00:07:34.640
For example, I don’t want to write all the internal native threading and consistency of the VM; we let the JVM take care of native threads, and that allows solid parallelism and solid native threading across all the Ruby applications you run.
00:07:54.560
I also don’t want to write a garbage collector that feels like black magic to me, so on the JVM, we have many different world-class garbage collectors, from small fast heaps to enormous multi-terabyte heaps.
00:08:15.759
Anything you can imagine for scaling in a garbage collector, we have an option for it on the JVM. Additionally, I write a JIT of sorts that turns Ruby code into JVM bytecode.
00:08:37.840
I don’t want to deal with the hard work of trying to compile that down to native code across all the different CPUs we want to support; we get that out of the JVM as well. With world-class just-in-time compilers, your Ruby code can turn into fast native code, ideally running much faster than running the interpreter or even the C Ruby JIT.
00:09:02.760
So, JRuby is kind of like a little VM built on top of a big VM, and we try to push as much of the hard stuff down to the JVM so that I can just yell at them to fix things rather than having to figure out how to fix it myself.
00:09:22.760
In terms of the compiler pipeline and how we get code into the JVM, we start with our Ruby code, which goes through our parser. Currently, it's a pure Java port of the C Ruby parser, but we’ll soon be moving to the new Prism parser that Ruby implementations can share.
00:09:41.800
The code will then run through our compiler, turning it into intermediate representations—essentially, our bytecodes for JRuby. After that, we have an interpreter for those bytecodes.
00:09:55.760
We interpret the Ruby intermediate representation for a while, and once we have called a method enough times and feel it's important to optimize it, I will run my JIT code that turns that Ruby bytecode into JVM bytecode.
00:10:15.400
Afterward, the JVM takes over and does the same thing over again. The JVM will interpret the bytecode for a while, profile the types, profile the paths through the code, optimize it, and then re-optimize it.
00:10:35.760
You'll notice this as you run JRuby code; performance will gradually ramp up and get much faster with time.
00:10:51.440
The JVM's JIT, specifically the standard JIT in OpenJDK, is the most widely deployed. It’s been around for at least 20 years, with many different levels of optimizations that are very stable.
00:11:10.760
We’ve worked closely with the JDK folks to ensure that it optimizes our Ruby bytecode well into native code.
00:11:24.880
We are also looking at other JIT compilers, such as GraalVM, which is a newer, more aggressive JIT compiler that can be plugged into OpenJDK. I’ll show some numbers on that a little later.
00:11:42.760
In addition, there are other JVM implementations out there; for example, IBM has its own implementation of the JVM called OpenJ9, which has its own JIT and features like saving compiled code in between runs and pre-optimizing code.
00:12:07.680
All of this can be utilized from JRuby because we are a JVM language and fit into that ecosystem.
00:12:28.559
Looking at JRuby on Java 8 through 17, one of the cool benefits of not having to write our own JIT is that as the JVM improves, JRuby improves.
00:12:51.760
There’s a saying in the Java world that if your application is too slow, just upgrade to the next Java version, and that’s usually true because they’re always finding ways to optimize code better.
00:13:08.760
If we look at a Mandelbrot generator script benchmark, we see the progression in how much faster it has gotten over time just by using different newer versions of the JVM.
00:13:24.560
From Java 8 up to 17, there’s nearly a 2x improvement without us doing anything at all, just switching to a newer version of the JVM.
00:13:36.920
In comparison, we also have a red-black tree benchmark, which shows a little bit less of an improvement over time because it involves creating a bunch of objects and walking them in memory; however, we still see steady improvement just by upgrading to newer JVM versions.
00:14:00.240
Incidentally, the Mandelbrot performance here is about 3.2 times faster than C Ruby with its JIT; the new JIT they’re working on is almost two times faster than C Ruby’s JIT. We are continuously trying to push that level up higher.
00:14:28.559
Overall, you can expect that pure Ruby code should be faster on JRuby than on regular C Ruby.
00:14:43.760
Now, I mentioned the Graal JIT: it’s much more aggressive about certain optimizations, and there are cases where it can do even better to optimize Ruby code.
00:15:01.440
For benchmarks like the Mandelbrot generator, which relies heavily on numeric operations and creates many float objects, the Graal JIT can see that these float object wrappers aren’t necessary and eliminate them, using the native float value instead.
00:15:14.919
This reduces allocation and garbage collection overhead. For benchmarks heavy on numerics or many small objects, the Graal JIT can provide substantial optimizations.
00:15:30.440
However, we don’t recommend using it all the time because there are instances where it doesn’t help as much; it can become overly aggressive, over-optimizing in some areas while missing other potential optimizations.
00:15:47.760
This makes it necessary to mix and match; you should try your code to see which versions of the JVM and JIT might work best for you.
00:16:06.440
Garbage Collection (GC) is another area to consider. I don’t want to manage a garbage collector myself, so we utilize the different JVM garbage collectors to handle various heaps.
00:16:22.360
This allows for different metrics, such as how long of a delay you want and avoiding pauses as much as possible. The JVM comes with many different garbage collectors as part of the standard OpenJDK.
00:16:39.600
Another cool feature of the JVM is the abundance of tooling surrounding all of these features. One such tool is called VisualVM, which uses the VisualGC plugin.
00:16:55.480
In this tool, you can see a live view of a Rails application benchmarked on JRuby, illustrating how the heaps fill up and how objects get garbage collected.
00:17:12.360
You should observe a nice steady sawtooth pattern as objects are allocated and cleaned up. If you were to see that line steadily climb without getting collected, then we would have a garbage collection issue.
00:17:28.240
This would indicate we've got a leak in JRuby, and the garbage collector cannot keep up with it, meaning we need to address a problem.
00:17:41.040
The core and standard library of JRuby, including core classes like String and Array, are implemented in Java, making them similar to C Ruby. Most of these classes are moving to Ruby over time.
00:17:53.160
The standard library primarily shares components with C Ruby; almost all pure Ruby gems utilize the same versions as regular Ruby. For libraries that have extensions, we usually have a JRuby version.
00:18:14.120
We have been collaborating with maintainers of standard library gems, like Hiroshi, to get those JRuby extensions into the library.
00:18:29.440
We’re still using the same actual gems, but many have a JRuby version of the extension. So, many thanks to all the maintainers working with us on that.
00:18:45.760
To give a visual overview of JRuby's code base structure, the Ruby parser is currently in pure Java, but we are moving toward a native parser called Prism.
00:19:00.360
This parser can be shared with C Ruby and Truffle Ruby, along with other implementations so that we’re not constantly porting the parser.
00:19:12.760
The internals of JRuby, unsurprisingly, comprise the compiler, the intermediate representation (IR), and our interpreter—all written in Java. The core classes consist of a mix of Java, Ruby, and some pieces in C.
00:19:28.480
The standard library shares a lot of Ruby code along with some pure Ruby that we share with regular C Ruby, but we also have some of our own JRuby extensions.
00:19:42.960
VisualVM is a profiling and monitoring tool you can use with JRuby, and there’s another tool known as the JDK Flight Recorder.
00:19:55.760
This tool allows for low-cost monitoring and profiling of even production applications, using only a couple of percent hit to your application’s throughput.
00:20:08.960
You can monitor performance by examining particular methods or objects that may be taking up too many resources. This view allows you to see Ruby Strings, Arrays, and blocks, which represent Ruby closures.
00:20:24.760
You can observe how many gigabytes are being allocated to these objects over time, allowing you to hunt down where in your code you're creating too many strings, arrays, or other objects.
00:20:38.760
There are also other tools in Mission Control and Flight Recorder, which you can utilize.
00:20:57.760
I mentioned the significance of contributions to JRuby; naturally, any JVM languages are fair game. If you want to write a library or a plugin for JRuby in Scala or Kotlin, it should work fine.
00:21:20.120
You can call those libraries from Ruby code and integrate them into JRuby. We strive to keep the codebase straightforward, so if there’s a core class, you can put 'Ruby' at the beginning of it—our Ruby version.
00:21:37.560
For example, RubyString, RubyArray, RubyHash, and so on.
00:21:54.480
We have multiple levels of complexity, so you can come in and work on a simple task like iterating over an array, or if you have ever done compiler 101 stuff at university, help us work on compiler optimizations at that level.
00:22:09.680
There are plenty of non-coding tasks as well. You can run tests on your favorite library, report things that don’t work, and test your applications to let us know what’s missing or what we need to fix.
00:22:25.760
We truly need the community's interaction to help keep JRuby moving forward.
00:22:42.760
I’d like to address performance and scaling applications, which has historically been a classic problem on C Ruby. Since we don’t have real parallelism with the threads in Ruby, we need to run worker processes.
00:23:12.960
No matter what you do, even with copy-on-write tricks or preforking, you still end up duplicating some resources. At the very least, each of those processes has its own garbage collector, operating independently, and that is not efficient.
00:23:30.760
Much more efficient is to have a single large process with a good garbage collector that can manage everything. JRuby believes it is an excellent, perhaps the best solution for scaling Ruby horizontally.
00:23:56.560
It's a single multi-threaded process that can run your entire site. Rather than having 100 workers to handle 100 concurrent users, you just need to adjust that knob in Puma, stating that you want 100 concurrent requests at a time.
00:24:05.440
As a result, you'll get 100 threads with one process managing the entire application.
00:24:27.680
As an example, consider a basic Rails application running on Postgres on an IBM virtual PC instance equivalent to about 8 CPUs and 32 GB of memory.
00:24:47.560
I ran this with C Ruby 3.2; the numbers haven’t changed significantly for 3.3. When you have 16 workers running on regular Ruby and 16 threads on JRuby, and you hit this as hard as possible, the performance metrics are telling.
00:25:00.240
This blog post app’s objective is to measure how quickly we can bring up one view of one post. JRuby does take a little while to warm up, and we’re trying to improve this aspect.
00:25:27.520
You’ll see a warm-up curve while profiling code, eventually optimizing it until it is transformed into JVM bytecode, with the JVM taking it from there and optimizing it to native code. Even with the warm-up time, JRuby comes out on top.
00:25:47.760
The request-per-second results show that JRuby achieves 1,700 requests per second, while C Ruby with YJIT accomplishes around 1,500. We’re not achieving vast gains using JRuby, but we consistently come out ahead.
00:26:09.600
Now, where it gets interesting is in terms of memory use. During testing with around 50 concurrent users without tuning JRuby, it ingested about 3.4 GB of memory—much more than needed, as the JVM is engineered to consume as much memory as it sees on the system.
00:26:28.880
You can modify and adjust this memory usage. In a separate instance where I limited the JRuby process to 300 MB of heap memory, the native memory requirement totaled just under a gigabyte.
00:26:44.160
Using the G1 garbage collector, which is a more memory-efficient version of GC, this came down to about 1.6 GB without tuning. On the C Ruby side, we need a process for every worker.
00:27:06.000
If we have 16 workers, each utilizing approximately 100 MB of Ruby process memory, that’s already 1.6 GB right there. Adding the YJIT logic incurs additional memory consumption, making the C Ruby side approximately 2 GB to achieve equivalent concurrency.
00:27:27.520
Going back to our request-per-second metrics, JRuby remains a bit faster. Even with the heap forced down to a much smaller size, it still surpasses performance compared to C Ruby with YJIT. If you analyze requests per second in relation to megabytes of memory, JRuby truly shines.
00:27:51.600
This is achieved with 16-way concurrency; JRuby is already ahead. Anyone doing cloud deployment knows you primarily pay for the memory you are renting, which is not easily shareable.
00:28:15.520
Thus, efficient memory utilization can save a significant amount of money.
00:28:32.560
By increasing concurrency to 180 and thereby illustrating the advantage of having a single process capable of supporting many parallel threads, we can reach up to 100,000 concurrent users with only a modest rise in total memory consumption.
00:28:51.440
In contrast, with C Ruby, each additional concurrent user necessitates an additional process, leading to further waste of resource memory. This scenario leads to real financial differences in deployment situations.
00:29:13.480
Let’s shift focus to something more enjoyable: one of the key advantages of the JVM includes support for cross-platform graphics and GUI libraries. Swing is built into the JDK as the classic Java GUI toolkit, easily callable and scriptable from JRuby.
00:29:36.480
It is simplistic, clean, and very cross-platform. You write your code in Ruby, and that code can be sent to someone else who can deploy it on JRuby without needing native libraries.
00:29:56.160
A similar toolkit is the Scalable Windowing Toolkit, which the Eclipse platform utilizes as its user interface; this connects with the system’s native widgets.
00:30:11.920
You can download and install it through one of the gems that wrap it, and it will function correctly out of the box.
00:30:29.920
There’s also the newer JavaFX, for which we have a JRubyFX wrapper. This is a more scene-based, vector-drawing graphics application that lends itself to a user interface modeled more after a web page.
00:30:53.760
Many Ruby libraries have wrapped these options and turned them into Ruby libraries that are easy to use, like the version four of the Shoes Library, which provides a quick and simple way to build user interfaces in Ruby.
00:31:11.600
This library actually runs on top of JRuby, enabling the creation of a graphical interface using JRuby without any additional installation complexities.
00:31:45.760
Another library I’m very excited about is Glimmer, which is a Domain-Specific Language (DSL) for building graphical interfaces, currently under extensive development with various backends and toolkits.
00:32:08.520
The version operating with JRuby and the standard window toolkit (SWT) is one of the most mature options available, allowing developers to build full-fledged desktop applications effortlessly.
00:32:24.640
The JRubyFX allows creating components using layouts and rectangles, scripting animations on a timeline; you can refer to the documentation to explore these developments.
00:32:44.440
Additionally, there’s even a plug-in system for Minecraft written for JRuby, enabling developers to create plugins in Ruby code that run within the Android environment.
00:33:04.680
In your interface, you can script all the logic and database access using Ruby, effectively combining both sides of the application.
00:33:23.520
We have a Rubat IRB demo application available; we used to have it deployed in the store, but it turns out that applications needing all system permissions faced challenges.
00:33:47.080
So that got pulled, but the APKs are available if you locate Rubat Core, which is JRuby itself, and Rubat IRB, the IRB interface to test out Ruby on your Android device.
00:34:06.600
We’re continuing to update this, working on integrating JRuby 9.4 and ensuring compatibility with the current Android features.
00:34:29.560
Now, let's discuss some of the new, intriguing JVM features that provide a compelling case for JRuby's future. The first is fibers.
00:34:49.600
We just saw an excellent talk from Visha and Isani on concurrency and fibers. I recommend you check it out for a deeper understanding of fibers—they are essentially micro-threads that allow for explicit rescheduling.
00:35:10.320
Compared to traditional threads, fibers stay on the same thread without OS context switching, allowing for switching between lines of execution hundreds of times.
00:35:33.680
Visualizing how fibers differ from threads can improve context. In a traditional threading model, an HTTP server would block while waiting for I/O requests, thus wasting CPU time.
00:35:49.840
In contrast, when using fibers, you can seamlessly jump to handle other requests on the same thread without wasting resources.
00:36:03.600
Traditionally, fibers in JRuby faced challenges. There was no way to implement native fibers and accomplish that explicit handoff efficiently in a thread.
00:36:40.480
This led to a simulation using threads, which are resource-intensive—in most operating systems, it’s tough to maintain thousands at the same time without application crashes.
00:37:01.520
Consequently, replicating the desired functionality for JRuby with thousands or tens of thousands of fibers became particularly challenging.
00:37:16.680
After many years of complaints, we told JVM developers that fibers—now termed virtual threads—needed to be integrated. Thankfully, this happened thanks to Project Loom.
00:37:30.560
As an open JDK project, Loom introduces real native fiber support, which allows JRuby to efficiently run tens of thousands or even hundreds of thousands of fibers.
00:37:48.040
I was thrilled when I received a stable build able to support virtual threads in JRuby without needing major code shifts. My single-line change allowed JRuby to utilize the JVM’s new structures, enhancing JRuby’s performance.
00:38:05.280
With this, JRuby can confidently handle 100,000 concurrent connections. The capability seen with Falcon's framework indicates the potential for Ruby to process a million concurrent requests, growing from JRuby.
00:38:21.760
Additionally, native libraries have been a challenge for JRuby. Ruby evolved alongside C, which directly influences how Ruby interacts with native libraries.
00:38:37.240
Native extensions are critical for augmenting runtime features. Over time, applications have transitioned to utilize FFI, which permits simpler, programmatic calls to C libraries instead of requiring you to write C code.
00:38:58.720
However, the migration process has taken time. As such, we need to support as much library functionality as possible, allowing developers to port applications to JRuby with fewer hurdles.
00:39:17.920
Regardless of potential compatibility issues, if an extension was built as a C extension on CRuby, it generally has to be ported to Java or some JVM-based language.
00:39:39.200
You might be able to use a pure Ruby version, which operates well under JRuby, but we usually recommend FFI or Fiddle to avoid coding in C or Java.
00:40:03.600
When using FFI, you can streamline the process, as shown in the structure involving user code on top of the native library calls running through a Java native runtime.
00:40:25.920
Ultimately, with additional transitions into JNI and then into the target library via FFI, performance lags behind expectations.
00:40:37.920
Fortunately, we have another JVM project on the horizon called Project Panama, facilitating optimized native FFI interactions with the JVM.
00:41:07.600
This project improves access speed by reducing the number of transition layers for native calls and also enabling memory allocation in native heaps.
00:41:22.360
Panama further provides a convenient API for generating stubs from C/C++ header files into Java codes.
00:41:30.560
We’re incorporating Panama into JRuby now, streamlining calls and improving performance and resource management.
00:41:47.760
Currently, SQLite support in JRuby utilizes a JNI plug-in to interface with the standard SQLite native library, but it's not highly efficient.
00:42:02.240
Our testing of Panama shows an impact of roughly double efficiency. This improvement would negatively affect performance for JRuby users working with SQLite.
00:42:13.760
Conversely, the Prism parser, a C library, is currently integrated through our FFI layer, but we’ll connect it to Project Panama soon.
00:42:28.960
This is anticipated to enable quicker Ruby parsing and significantly enhance performance overall.
00:42:40.440
Speaking of the future of JRuby, JRuby 9.4 is the current stable version, compatible with Ruby 3.1, and runs Rails 7.1 excellently.
00:42:55.760
It is evolving towards a maintenance phase, finishing compatibility work while also beginning enhancements pertaining to performance.
00:43:10.680
We are nonetheless excited about the future features in the JVM and what they can offer JRuby.
00:43:26.560
For instance, I can make a significant announcement regarding JRuby 10, which will be our next release.
00:43:42.000
We’re really looking forward to this big leap forward, focusing on Ruby 3.4 compatibility, which hasn’t even been released yet on the CRuby side.
00:44:00.840
We plan for JRuby 10 to release around the same time as Ruby 3.4 this year, while we're also moving up to a minimum of Java 17 or possibly Java 21.
00:44:16.560
The motivation to switch to Java 21 arises from native fibers gaining entry into the JVM, enabling developers to leverage this without needing workarounds.
00:44:35.720
We will incorporate the Prism parser, maintaining our standard Java parser for instances without the native library being available.
00:44:51.040
We have already initiated exciting optimizations regarding our ability to move to the newest version of Java.
00:45:08.960
This will give us access to numerous optimizations and APIs previously unavailable. This leap forward represents the most significant development we have witnessed thus far.
00:45:24.880
Therefore, we are actively looking for contributions in this area that can assist the JRuby team.
00:45:40.240
What’s your role in helping build JRuby 10? We will be making a significant jump from Ruby 3.1 to Ruby 3.4.
00:46:01.360
We need the input and help from users like you to help implement new features that could also be written in Ruby.
00:46:17.480
If there are core Ruby functions that can simply be translated to Ruby, you’re invited to submit them.
00:46:30.720
This way, base optimizations can be retained; if some functions need special attention, we find alternative optimization routes.
00:46:46.160
Testing your libraries and Ruby applications will also help. Run 'bundle install' with JRuby on your application and let us know which native extensions you may be missing.
00:47:01.840
Inform us of libraries that aren't available to fill the gaps, which would make JRuby functioning smoothly for you.
00:47:17.040
We need help managing around 700 open bugs; I assure you that not all of them are valid anymore.
00:47:32.880
I used to sift through all those bugs every few months, and it took an immense stay on my part; any assistance in this context would be incredibly helpful.
00:47:50.279
We’re always available to work with you. Jump into our channel on the Matrix chat framework—an open-source alternative to Slack.
00:48:00.960
Feel free to direct your questions or express interest; we are happy to guide you and facilitate entry-level tasks that lead to contributions to JRuby. There are usually a few of us available in that space.
00:48:15.600
All of our developmental discussions occur out in the open, so join the team, and that’s all I have for you today. Thank you very much!
