Of high-level note:
- Ruby 1.8.7 is the new Baseline - This promises a number of library changes and backports from 1.9. To see the 1.8.7 changes you can look here.
- Ruby 1.9 Compatibility Improvements - As mentioned in the blog entry, Ruby 1.9 is a moving target, however they are moving a lot closer to having major libraries working as desired. Some high-visibility features (like Fibers) are still on the pending list, however.
- New YAML Parser - Ola Bini re-visited the YAML parser in Ruby recently (he has blogged about the creation of the new parser and how he ported it). The new parser, Yecht, is said to be completely compatible with Syck (the Ruby parser), warts and all.
- Java Method Dispatch Improvements - One of the major promised features of 1.4 for quite a while has been improvements to the Java integration; they have been wanting to formalize this portion of the language for sometime. This involves calling Java methods, calling overloaded Java methods, the coersion of types (Java string <–> Ruby string), etc. Charles Nutter has posted a very detailed, developer-centric breakdown of the plans in this integration on the Developer mailing list (which goes beyond what’s available in the blog entry). Certainly an interesting read.
- Java Class Generation via JRuby - JRuby will finally be able to construct runtime-available Java classes on the Java classpath. This will be available on-demand only, however that could be quite handy in a number of difficult integration scenarios.
This set of features is exciting to me, particularly for the Java integration features. The current Java integration functions, but can be somewhat tempermental, and can end with surprising results at times (I have learned this the hard way via hand-coding Swing and SWT apps).
Additionally, one of the killer features of Scala, in my opinion, is its ability to interact seamlessly with Java libraries at compile-time (create a class in Scala, and code against it in Java). While the semantics defined for JRuby are more runtime-centric for now, it does provide an ability to construct something that can be fed into Java APIs at runtime that expect certain “inferred” contracts to exist (such as the Jersey example they used in the original post).