What's it all about, Alfie?

I've been working with Jeff on some changes to the threading model of our app, and I have to hand it to Ruby/JRuby - the exposure of Java's Executors is really very nice:

  require 'java'
  java_import 'java.util.concurrent.Executors'
 
  executor = Executors.new_fixed_thread_pool(10)
  work.each do
    executor.execute do
      begin
        # do all my work here
      rescue => e
        puts e.backtrace.join("\n")
      end
    end
  end

and the beauty of the design is that we now have 10 threads for any number of tasks that need to be done in 'work', and the Executors will handle all the processing and thread management and all the stuff you'd once have to have done manually - it's now free.

This isn't new to Java, but it's really nice that it's sitting in JRuby for free. Very nice.

The problem is that when we get a Java stack trace, it's next to impossible to figure out what's going on. Face it, ruby is dynamic, so the Java classes that are created have a passing resemblance to the original ruby class, but they have been munged into what's needed by a non-dynamic language: Java. It's possible to get some idea, but it's not a lot, and today it's turned out to be not nearly enough to figure out what's happening.

Again, the best debugger is a sharp developer, and that's what we have to go with, but it's just too bad that the JRuby crew didn't foresee this and make something that can take the Java stack trace and turn it into what a ruby developer's stack trace might look like.

Now that would be neat.

This entry was posted on Friday, July 27th, 2012 at 1:27 pm and is filed under Coding, Open Source Software. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.