With JRuby 1.2 almost out the door, I want to talk a bit about where we should go with JRuby 1.3. There's always more work to do, but in this case there's a few different directions we could probably go.
Some obvious items will continue to see work:
- 1.9 libraries, interp, compiler, parser
- 1.8.6 bugs
- "Pure ruby" application support, like Rails deployment stuff (Warbler, AR-JDBC)
- 1.8.7 support
- Ruby execution performance (how fast do you want it?)
- Specific library performance (YAML, IO, Java)
- More Java integration improvement/refactoring (esp. subclassing)
- "Compiler #2" to produce normal Java classes from Ruby
- Improvements to AOT compilation (all-at-once, eliminate runtime codegen)
- Expand support for embedded/mobile platforms
- Start generating most of the call path, to reduce duplicate code
- Specific-arity optimizations for block yield (could be big)
- Compiler cleanup and refactoring
- Modularization of core classes that aren't valid on applet, Android, secured envs, etc; also may allow shipping smaller runtimes
- More startup perf work; I have a few ideas
30 comments:
Hello Headius,
Here is my top 3:
1. Ruby Execution Performance (I don't how faster but I would say as fast as we can get).
2. Compiler #2. Produce normal Java classes from Ruby (this would be a killer feature).
3. JFFI performance improvement and support for more platforms (AIX, Mainframe USS? etc...)
Thanks for getting the community feedback!
My top items would be "More Java integration improvement/refactoring (esp. subclassing)" and "'Compiler #2' to produce normal Java classes from Ruby". I'd love to be able to put together an executable JAR from straight JRuby code, containing inherited classes that get passed out of that jar for instantiation & execution.
I also realize that I'm doing some kinky stuff, and I might be an edge case. :-)
Thanks for giving the users a chance to weigh in on this.
Same as JD__ for me ;)
BTW, what you have done with JRuby is amazing. What is even more amazing is how many cool things are just ahead of the corner ;)
I don't have an Android phone, but the Ruboto thing is great too !!
Same as Brad: subclassing and compiler #2, although I'd add the AOT compilation.
1. Compiler #2! Compiler #2!
2. Performance.
3. Modularization.
Thanks!
In no particular order:
AOT
Compiler #2
Execution performance ( keeping at or near the head of the pack. )
1. "Compiler #2" to produce normal Java classes from Ruby
2. Performance
3. More Java integration improvement/refactoring (esp. subclassing)
Don't bother with Ruby 1.8.7 support. If people want these new features, they should just go ahead and switch to 1.9-mode.
I'm most interested in the promise of the improved compiler. Clojure interop would be interesting too for folks who want to push the FP envelope.
1. Startup perf work
2. Performance general
3. Rails deployment
Hey Headius,
thanks for asking ;-)
Ruboto rocks. I guess the following two would help it the most?
"Improvements to AOT compilation" and "Compiler #2".
Btw. (a) how big is the app you deployed? (b) Yes, the BufferedReader warning in the log is really annoying, especially because standard libraries use the default constructor too.
1. Performance
2. "Compiler #2" to produce normal Java classes from Ruby
3. More Java integration improvement/refactoring (esp. subclassing)
Hi Headius,
for me it's Performance (of Rails stack to be exact). I don't really care about anything else JRuby has to offer at this point :(.
Charles,
The #1 killer feature for JRuby (IMHO) is being able to use JRuby classes from other JVM langs with as little fuss as possible. Other JVM langs have been able to pull this off and it has made their interoperability a compelling proposition. My guess is that this is perhaps the hardest thing to do of the options you threw out there.
Thank you for asking!
The biggest issue we hit today is not with JRuby itself, but with running Rails on JRuby in an app server. Glassfish v2.1 throws a lot of errors and warnings that are not easily decipherable, and the deploy memory leaks are really bad.
I would focus some time on getting that aspect of the stack really solid. I know this is not really JRuby-core, but it is a critical part of the experience.
I vote for full Ruby 1.9 compatability (assuming it's not already there).
Also, allow time for FFI documentation/support/evangelism. It would be great to get all those ruby gems with C dependencies converted.
Once we can run our apps with caring if we're on MRI or JRuby, the sky is wide open!
I vote for Rails deployment stuff.
I'd echo the jruby error stack like the one spewed when called inside glassfish. Something to simplify web integration and deployment. For example rack is supposed to be the simplest thing but jruby-rack is like a black box. Code is hard to figure, just to get logging working properly when deployed in a container is an exercise as hard as reverse engineering a protocol.
I vote for "More Java integration improvement/refactoring (esp. subclassing)".
# "Pure ruby" application support, like Rails deployment stuff (Warbler, AR-JDBC)
# More Java integration improvement/refactoring (esp. subclassing)
There is some missing standard stuff that'd fall in Java integration esp. web integration. Like a RubySevlet.
I moved from java to jython to ruby to jruby. One thing I really liked from my jython days was PyServlet.java. I have an app from 3-4 years back still chugging along well with the simple piece of PyServlet and related code goodness. It was a great help that example came with the standard distribution and is a pretty solid piece of code. It is pretty cool to Warble-r and other command line magic stuff but there is something about the simplicity of the model. I mean it's great ruby world is/has been dominated by rails but in the standardized (web) world of java you gotta have a Servlet. It kind of complicates things when a web server team (glassfish) is selling/pitching/releasing a gem every few months for better jruby integration. There should be some not-so complicated default way.
For a RubyServlet/Filter.java all that is needed is a functional java class that has methods for instantiating an interpreter, a pool/multiple of interpreters, load/evaluate a ruby file/string, some form of caching I guess and all this with thread safety. Other standards like Rack can build on top of this I guess.
IO speed.
1. Compiler #2 / Java Integration
2. Execution Performance
3. Internal cleanup
Hello Headius,
as a happy user of android I would welcome any improvements I could enjoy on my android. Thank you for your work
1) Compiler #2
2) generating most of the call path, to reduce duplicate code
3) More startup perf work
Performance is important to me, specifically I noticed that an app doing heavy pattern matching was slower on JRuby compared to MRI (1.1.4 was same, 1.1.5 was slower). This prevented me from using JRuby.
Hello,
for me it would be
* Rails deployment stuff
* Compiler #2
* Performance
Would "more Java integration" include such things as java.lang.String == String? Because that sure would be handy.
I tried jruby on rails on glassfish on my joyent solaris host and it worked fine, although the memory footprint was too high relative to mongrel so I had to drop it. I've since dropped mongrel too for phusion passenger (mod_rails) deployed as an apache http server plugin with performance gains and even lower memory footprint over mongrel.
Can jruby on rails be set up to run via apache plugin too? If not, is that something that would be worth considering for 1.3? The argument in favor of it would be simpler setups and deployments for developers and startups with low system resources, or for those running multiple sites on one system in early business stages.
Thanks,
Rene
Douwe: We would love to have a Performance bug reported for anything you see that's slower in JRuby. Pattern matching should definitely not be slower, but it's possible you've found an edge case.
Hi, i just saw your JRuby talk from oredev 2008 at google video. What text editor were you using? NetBeans?
schildmeijer: Yep, I'm sure it was NetBeans.
Post a Comment