Tuesday, February 26, 2008

JRuby in Google Summer of Code 2008

Greetings!

Google's Summer of Code for 2008 is starting up again, and we're looking for folks to submit proposals. The JRuby Community or Sun or me or someone will sign up as a mentoring organization, so start thinking about or discussing possible proposals. Here's a few ideas to get you started (and hopefully, there are many other ideas out there not on this list):

  • Writing a whole suite of specs for current Java integration behavior...and then expanding that suite to include behavior we want to add. This work would go hand-in-hand with a rework of Java Integration we're likely to start soon.
  • Collect and help round out all the profiling/debugging/etc tools for JRuby and get them to final releasable states. There's several projects in the works, but most of them are stalled and folks need better debugging. This project could also include simply working with existing IDEs (NetBeans, etc) to figure out how to get them to debug compiled Ruby code correctly (currently they won't step into .rb files).
  • Continue work on an interface-compatible RMagick port. There's already RMagickJR which has a lot of work into it, but nobody's had time to continue it. A working RMagick gem would ease migration for lots of folks using Ruby.
  • Putting together a definitive set of fine and coarse-grained benchmarks for Rails. JRuby on most benchmarks has been faster than Ruby 1.8.6...and yet higher-performance Rails has been elusive. We need better benchmarks and better visibility into core Rails. Bonus work: help nail down what's slower about JRuby.
  • Survey all existing JRuby extensions and put together an official public API based on core JRuby methods they're using. This would help us reduce the hassle of migrating extensions across JRuby versions.
Please, anyone else who has ideas, feel free to post them here or on the mailing list for discussion. And if you have a proposal, go ahead and mail the JRuby dev list directly.

Update: Martin Probst added this idea in the comments:
Another idea might be to "fix" RDoc, whatever that means. That's not really JRuby centric, but still a very worthwhile task, I think.

A documentation system that allows easy doc writing (Wiki-alike) and provides a better view on the actual functionality you can find in a certain instance would be really helpful. Plus a decent search feature.
And that makes me think of another idea:
  • Add RDoc comments to all the JRuby versions of Ruby core methods, and get RI/RDocs generating as part of JRuby distribution builds. Then we could ship RI and have it work correctly. Ola Bini has already started some of the work, creating an RDoc annotation we can add to our Ruby-bound methods.
Update 2: sgwong in the comments suggested implementing the win32ole library for JRuby. This would also be an excellent contribution, since there's already libraries like Jacob to take some of the pain out of it, and it would be great to have it working on JRuby. And again, this makes me think of an few additional options:
  • Implement a full, compatible set of Apple Cocoa bindings for JRuby. You could use JNA, and I believe there's already Cocoa bindings for Java you could reuse as well, but I'm not familiar with them.
  • Complete implementation of the DL library (Ruby's stdlib for programmatic loading and calling native dynamic libraries) and/or Rubinius's FFI (same thing, with a somewhat tidier interface). Here too there's lots of help: I've already partially implemented DL using JNA, and it wouldn't be hard to finish it and/or implement Rubinius's FFI. And implementing Rubinius's FFI would have the added benefit of allowing JRuby to share some of Rubinius's library wrappers.

12 comments:

Martin Probst said...

Another idea might be to "fix" RDoc, whatever that means. That's not really JRuby centric, but still a very worthwhile task, I think.

A documentation system that allows easy doc writing (Wiki-alike) and provides a better view on the actual functionality you can find in a certain instance would be really helpful. Plus a decent search feature.

sgwong said...

Add win32ole support into Jruby, either using Jacob or other existing Java to com bridge or JNA?. The win32ole usage should be same as MRI ruby win32ole because using win32ole in MRI is easy and I like the olegen which can generate the whole COM dll class in ruby.
Well, this is my point of view. I am a windows user and I use a lot of COM dll in my program. Support for win32ole is a nice feature for windows user.

Charles Oliver Nutter said...

@sgwong: That's a good one. We had someone start on it, but then they disappeared without submitting any code. And there's the Jacob library for COM in Java that would take much of the pain out of it. I'll update the post.

David Koontz said...

Along the lines of getting the Win32 library is an implementation of the Win32Utils library (http://rubyforge.org/projects/win32utils). Daniel Berger (the maintainer of the existing library) had mentioned that he had started on this in a recent blog post (http://www.oreillynet.com/ruby/blog/2008/01/jruby_meets_the_windows_api_1.html).

LeonB said...

You guys really kick ass! The Rdoc improvements sound great. Jruby has some bugs at the moment, so it doesn't work for me right now. But I'm watching your progress with interest.

Mike Hoskins said...

As much as Cocoa and Win32OLE are important (and they are important to me, too), how is POSIX support going for JRuby?

I'd like to be able to do fork() and trap() and the like (assuming all this can be done in Java).

BTW, JRuby is super cool. Thanks, thanks, thanks.

Charles Oliver Nutter said...

@mike hoskins: POSIX support is actually going really well now that we're using JNA to hook into native libraries. We have support for a number of features even Java SE doesn't like symlinks, file permissions, and stat. Your signal trapping is supported as well. Fork is in there too, but as it's probably not a very clean or safe way to live on a JVM (that's a big process to be forking) it's normally disabled and most JVMs will warn you loudly if you try to use it. But it's there, and all other POSIXy features we need to match Ruby are coming along as well.

Shane said...

This is going to sound out of left field, and people will probably hate me for it, but you know what I'd like to see for JRuby? Good documentation. One central repository that contains everything in a well-organized and easy-to-find way. Thus far, in my efforts to figure out how to do stuff like implement Java interfaces, make Enums, use generics, I've had to search all over hell and back, collating bits of information from blogs, newsgroups, the wiki, etc. etc.

The main JRuby site is abysmal and looks like it was made by a ten year old in 1997. Everything about it lacks polish. If you want to make it easy for people to adopt it, try it out, play with it, get involved, making the information very easy to find, and the documentation as thorough and well-organized as possible, would be very good starts.

Please don't take this the wrong way; I am so excited about JRuby in particular, and in general Sun's awakening to the amazing potential of Java/the JVM as a new fundamental layer for development. I very much appreciate all the paid and voluntary labor that's gone into this. But seriously - can't sun fork out 20/hr for some undergrad to tidy this up? The cost/benefit is soooo tiny...

Anton Arhipov said...

What about the performance issues? Are you satisfied with JRuby performance?

Charles Oliver Nutter said...

@shane: yes, you're right about docs and internet presence for JRuby being a little weak. As it stands, we're a little resource-limited, and it wouldn't be a good use of either Tom's or my time to tidy up docs or the site. So we're really hoping folks from the community can do more to help. We're willing to give the keys to the castle to anyone who wants to make things tidier or gather docs together better.

@anton: We'll probably never be "satisfied" with JRuby performance, but for the moment general performance appears pretty good. There's a world of improvements we could make, however, and we're certainly interested in that as a GSoC topic if someone wants to try to take it on.

Anton Arhipov said...

@Charles: I will apply to this one ;)

Tony Hursh said...

Unfortunately the Cocoa-Java bridge is deprecated since 10.4. If someone takes on that project, using JNA would probably be a better choice.

Weird. Blogger wasn't giving me a word verification image in Firefox, just the alt text. Trying again with Safari. Apologies if this winds up getting posted more than once.