Brennan Spies's blog
Tucked inside the somewhat innocuous announcement that a new committer has joined the Rails core team (Josh Peek, who had worked on Rails via the Google Summer of Code) was the surprising revelation that Ruby on Rails 2.2 will be thread safe. Even more surprising was the statement:
The actual thread safety won’t really matter much to most people, but it’ll surely look nice on your enterprisey check list of Features Your Framework Must Have To Get Play Around Here.
Huh? Thread safety not important? As much as I sometimes feel nostalgic about 1990's CGI programming (ah, signing bonuses...*sniff*), statements like that are just plain embarassing, and don't do much to promote Ruby or Ruby on Rails. And before anyone counters that stable versions of Ruby still don't use native (kernel) threads, think again: JRuby does. It may well turn out that JRuby + RoR 2.2 will be the the power combo for Ruby developers in 2008 and beyond...those that are serious about concurrency, at least.
The details of what the new unified specification will look like are far from finalized at this point, but clearly it will be a very scaled back version from the ambitious ECMAScript 4 proposal. Some early results:
- Packages, namespaces, and early binding from ES 4 are off the table for good.
- ES 4 classes are being "rephrased": they will now be syntactic sugar for lambda-coding and Object.freeze() (which was proposed in ES 3.1)
- ES 4
letexpressions seem to have some general agreement among committee members.
The announcement has sent ripples across the Web. Adobe, which had built ActionScript 3 to closely match anticipated ECMAScript 4 features, has maintained that they will not change AS 3 at all in response to the new direction. Some have speculated that Microsoft's motivation in bucking the ECMAScript 4 standard--and certainly the main factor in why it was abandoned--was political.
The Yahoo! User Interface development team has released the first preview version of YUI 3.0. According to the team blog, there are 5 goals for the new release: lighter code (in kb), faster code (fewer HTTP requests, more compact code), greater API consistency, more powerful API capability, and more securable code.
- Sandboxing: each YUI instance can now be separated from other instances via
- Modularity: YUI 3.0 is architected to use smaller, more re-usable modules.
- Self-completing: With the seed file in place, you can tell YUI what modules you want to use, and it will download them in a single HTTP request.
- Selectors: Elements can be targeted via CSS selector idioms (much like jQuery)
- Enhanced Custom Events: Custom Events in YUI 3.0 have been enhanced with support for bubbling, stopping propagation, assigning/preventing default behaviors, among other things.
- Nodes and NodeLists: You can now reference elements via Node and NodeList facades, allowing a more fluid API.
- Chaining: YUI is adopting a fluent interface style, using method chaining to achieve greater expressiveness (and compactness)
For those who don't like the jQuery-style fluent interfaces in YUI 3.0, a more explicit/verbose API is still available. YUI 3.0 will not be completely backward compatible with YUI 2.0, but there will be a limited compatibility layer.
You can download the preview release here. A final release is not anticipated until next year.
From the "snuck by me department": CGLIB 2.2, which had hovered in beta for a seemingly endless period of time, became final in May of 2008. The brief release notes explain that it contains a patch for a race condition in MethodProxy as well as an upgrade to ASM 3.1. For those who aren't familiar with CGLIB, it is a very lightweight Java library originally created as a faster alternative to
java.lang.reflect.Proxy. It has seen use in many well-known projects such as Hibernate, Spring, and more recently Google Guice.
Actually, the title should be "The Next Great Mid-Level Language", but doesn't sound quite as snappy...
There has been a lot of talk in the last year or two about Java losing ground to newer languages and about which language is going to replace Java as the dominant language going into the next decade. Various factions from the Ruby and Scala camps have weighed in on the debate in earnest, leaving even some die-hard Java programmers wondering if they should be learning a new language (and soon). After all the smoke clears, what should the reasonable person conclude? Is it time to move on?
In an attempt to beef up its ad-search business by opening up its search technology, Yahoo has launched a new program called BOSS (Build your Own Search Service). The move is part of the new "Yahoo Open Strategy", a strategy that aims to attract more users and developers to Yahoo's technology and services by opening them up. It's not a totally free lunch, of course, as traffic over a certain "query threshold" will require some type of agreement with Yahoo, either hosted ads, revenue, or some type of exclusivity agreement.
With this first release of BOSS developers can fetch search content for Web, News, Image, and Spelling Suggestions. The API itself is a RESTful web service, with the option to receive data back from the service in JSON or XML formats. Full documentation on the search API is here.
Ext GWT 1.0 has been compiled and tested against GWT 1.5 RC1. Downloads are located here.
The Scala programming language, heralded by many of the Java cognoscenti as the language to replace Java, has garnered well-deserved praise as a sophisticated and capable language. But to many who have grown up in the tradition of C-C++-Java, Scala's hybrid imperative-functional design may be just too alien to their sensibilities. Given the history of popular programming languages, this is not a surprise. It was, after all, not Smalltalk but C++ that introduced OOP to the masses; and Java in no small way gained popularity by fixing many of the pains involved with programming in C++ while still retaining the same general style of syntax.
Now along comes a language called Fan, which takes a more evolutionary (as opposed to revolutionary) approach to language design, incorporating concepts from Java, C#, Ruby, and other languages (e.g. Erlang) into a fluid style that would be very comfortable for a programmer well-versed in any of these languages.
Here is a short list of interesting features in the Fan language:
- Compiles to either JVM or .NET bytecode.
- A Ruby-like syntax for using closures (with the method signature expression enclosed between two "|"). Like C#, functions are first-class citizens in Fan (represented by the Func class).
- Fan has no concept of interface classes, but rather uses mixins for multiple inheritance. Mixins are like abstract classes in Java (i.e., they can declare concrete method implementations), but can contain no state (i.e., fields). This addresses one of the weaknesses of interfaces in Java (and C#), namely that it is very difficult to introduce new methods into the interface without breaking all of the existing implementations of this interface; this is a problem in widely-used public-facing APIs such as the Collections API in Java.
- All threads in Fan have the ability to pass messages to other threads, i.e they use the Actor model for concurrency popularized by Erlang.
- Fan is, generally speaking, a strongly and statically typed language. But Fan supports a special syntax for using dynamic typing with a "dynamic call operator", the "->". This operator allows you to call a method on a class without the compiler enforcing type checking. In other words, you don't have to cast a type just to call a method.
- A unified namespace and deployment structure. The deployment unit in Fan is called the "pod". The first part of a namespace is always the deployment unit (pod), so identifying a missing class becomes much easier than the "jar hell" of Java (though arguably Maven makes this much easier).
- Fan supports a "literal syntax" for programming with lists, maps, etc. that makes working with these common elements much easier.
More thorough documentation on the language is available here. In general, Fan does not introduce any world shaking concepts--certainly all of its elements are present in some form or another in other programming languages--but is distinguished by the fact that it makes very smart decisions about which features to use, combining them in a style that is both fluid and familiar to the average programmer.
After CommunityOne and the initial rush to JavaOne on Tuesday, Wednesday for me was a bit less eventful. The highlights of the day included Neal Gafter's talk on Closures and Gavin King's introduction to Web Beans. For those who have already been following the Closures proposals (and debates) for the Java language, Neal's talk didn't really contain much that was new other than concrete examples for how closures would be used in the real world (hence the title "Closures Cookbook"). Gavin's presentation was a little more interesting for me, primarily because I had not really spent that much time looking at Web Beans. Web Beans, for those who don't know, is a component model for objects in the web tier. It borrows ideas from Seam and Guice and, well, standardizes them. This has been an increasing trend in Java, and a good one: take the best of the ideas from Open Source, and move them into the standards space. But with all the new specifications being aimed at developers in this space (EJB 3.0, JSF 2.0, Servlet 3.0, etc.), I wondered a bit if there wasn't just a little specification overload happening here.
By Thursday, most attendees are starting to feel what is commonly referred to (in professional circles) as "PowerPoint fatigue". I was no exception. One session that really alleviated some of the fatigue was Martin Odersky's "Programming with Functional Objects in Scala". For those who don't know, Scala is a new programming language created by Odersky himself. Though it targets the JVM, it is a very different language than Java: functions/methods are objects which can be sub-classed (!); the language uses mixins ("traits") instead of interfaces; it is statically type-inferred; and the list goes on. The slide where Odersky showed Erlang-like actors in Scala really floored me; clearly, this was a sophisticated language.
The other fatigue reliever, "The Future of Guice", contained almost no information but was the perfect counterpoint to the rest of the conference. Bob Lee and fellow cohorts from Google (including Joshua Bloch himself, who showed up for the presentation) provided free beer, free books, off-the-cuff jokes, and generally a good time. I still have very little idea of what Guice 2.0 will be like but--what the heck--I'll read the documentation when it comes out.
As in past years, Friday is the winding-down period of the conference. The show floor is already empty, and a lot of people are thinking about other things. Nevertheless, the intrepid contention-goer can still squeeze some last nuggets of wisdom before the end, and this year I was able to do exactly that. My most practical session of the entire conference was on this day, "Automated Heap Dump Analysis" by Andreas Buchen and Krum Tsvetkov from SAP. I've spent some time doing profiling with one of the best (JProbe), but I must admit this was a pretty slick tool. For those who are interested, the SAP Memory Analyzer is open source and freely downloadable.
I ended the conference with Rod Johnson's "Spring Framework 2.5: New and Notable". Rod spent a fair amount of time on both the new @AutoWire dependency injection annotation as well as the OSGi-enablement of Spring itself. For those who have been following Guice, the first was nice but no big deal. The second (the integration of OSGi into Spring) was much more interesting given the move of many big application server vendors--WebLogic, WebSphere, Glassfish, etc.--to OSGi as the modularization and versioning platform of choice.
And, just like that, JavaOne was over. I rode up the escalator in the Moscone Center with a slight tear in my eye and a fistful of receipts for my expense report. Well, here's to next year...