Check Out the Play Framework

March 1st, 2010

play
I’ve spent a lot of time recently investigating a variety of languages other than Java, such as JRuby and Scala, and truly believe from these experiences that traditional Java MVC web frameworks are inherently flawed in design and implementation. The effort involved in implementing on a framework like Struts or Spring MVC is astronomical, especially if you are going to implement things “the right way”.

It’s amazing to me how much these platforms push “hello, world” examples that are simply not realistic web applications. After trying these short examples, developers turn around and start trying to implement a complete application, and this simple example balloons into a mess of code, and that’s without any real functionality yet in the application. A co-worker of mine is a fan of saying “[These frameworks] make the simple things trivial, and the hard things impossible”.

Historically, I’ve been known to say “If you are doing web-development in Java, use Wicket“; this was based on the fact that to my experience Wicket took the most advantages from the strongly-typed, and strongly IDE-supported, Java language, as opposed to trying to hide them behind anemic and broken templating languages that have horrid editors and basically trade one problem for another.

Recently, however, I spent some time doing some significant development with the Play Framework. I have to say that I think the Play Framework has eclipsed my Wicket fever. That’s not to say that I don’t still think Wicket is very powerful, but I have been particularly impressed with the feedback loop provided by Play. It has, without a doubt, the most direct code-test-cycle I have seen in any platform for Java (it approaches the instant feedback of Rails), and also has the distinct advantage of being stateless out-of-the-box (something Wicket is definitely not).

Play manages this feedback loop problem in a rather novel way – embedded in the framework is the Eclipse compiler for Java (ECJ). This means that when you’re coding for the play framework, you’re not sending it your class files, but rather your source files. This allows Play to recompile code in a running instance on the fly – I literally only restarted my application a handful of times while I was coding over the course of several days. It also integrates seamlessly with IDEs, and ships with an embedded HTTP runtime (no deployment is necessary during development).

There are a number of other benefits Play can provide by working with source files instead of class files. Much like Rails ability to add functionality to your application at runtime, Play can (and does) pre-process certain Java classes to add functionality.

I was further heartened to see that the next release of Play is meant to fully support Scala, which would allow for other modern language features to be used with this highly interactive framework.

It’s hard to describe all of the neat features Play provides in a few hundred words, but I would highly recommend you check it out – they have a 10 minute screencast they sells it better than I can. While I’m still convinced Java (as a language) will be surpassed for an overwhelming majority of the web-development as the language continues to stagnate, this is a compelling framework for the Java platform as a whole, even if Java isn’t your language of choice.

JRuby “IO.foreach” Performance

November 3rd, 2009

Ruby LogoI’ve been spending some time dipping my toes in patch contribution for JRuby recently. I started with a few easy, isolated, spec issues, and have since been working my way into more entrenched problems. The past few weeks I spent a good bit of time toying with solutions to JRUBY-2810: “IO foreach performance is slower than MRI”. The exercise was interesting enough, that I thought it might be worth posting here. This isn’t meant to be a study of the JRuby code in particular, but more-so in the thought process of diagnosing a performance problem in foreign code. Read the rest of this entry »

Fistful of Awesome: IntelliJ Open-Sourced

October 15th, 2009

In a surprising move, the JetBrains team has decided to open-source the JavaSE portions of IntelliJ IDEA 9.0 and beyond under an Apache 2.0 license. They will begin offering two products, a community edition, and an ultimate edition:

Starting with the upcoming version 9.0, IntelliJ IDEA will be offered in two editions: Community Edition and Ultimate Edition. The Community Edition focuses on Java SE technologies, Groovy and Scala development. It’s free of charge and open-sourced under the Apache 2.0 license. The Ultimate edition with full Java EE technology stack remains our standard commercial offering. See the feature comparison matrix for the differences.

Very cool news! The impact in competition for other IDEs (namely Eclipse and NetBeans) remains to be seen, but this certainly brings another aggressive (and already well-liked competitor) to a broader market.

WordPress 2.9 Beta Testing Call to Arms

October 13th, 2009

wordpress-logo-stacked-bg

“For a limited time only – you can beta-test WordPress 2.9 from the comfort of your own installation!”

In the “another reason I like WordPress better for blogging” category, the folks over at WordPress.com have published a detailed article on how WordPress users can get involved in the beta-testing of WordPress 2.9 – the next major release. Included in the options for aspiring beta-testers is a plug-in that will automatically upgrade your site to the new version, and will keep you on the up-and-up. Read the rest of this entry »

What Am I Downloading Today, Eclipse?

October 8th, 2009

With the release of Eclipse 3.5, the plugin installation and update manager was completely revisited once again; the update process was reorganized, and the strengths of the p2 provisioning framework were surfaced. It’s nice to be able to hop in, download updates, and go.

However, I think Eclipse, as a product, still has a way to go. Read the rest of this entry »

Distilling JRuby: The JIT Compiler

October 6th, 2009

Ruby Logo
The JIT compiler in JRuby is a relatively new creation for JRuby. Of course, the initial approach taken for the JRuby platform was the most straightforward: parse and interpret the code incrementally as the program executes, traversing the AST. As time went on, the JRuby team have taken a bunch of steps to improve the performance of JRuby, most of which have involved shortcutting the consistent, but also slow and indirect interpreter model. The JIT compiler is probably one of the most aggressive and technically complex steps taken to date.

JIT compilers are a novel idea: take some code in an “intermediate form”, and, given some heuristics, compile it into a “more native” representation, with the expectation that the more native version will perform faster, and allow for more optimizations by the underlying platform. If some optimizations can be thrown into the more native form in the process, all the better.

Java, as an example, has had a JIT compiler for several years now. In fact, Java was, for many developers, the first time they heard the term JIT; so much so that many developers I know think the “J” in JIT stands for “Java”. In fact, JIT stands for Just-In-Time. Smalltalker’s may recognize the term “Dynamic Translation” instead.

Anyway, when the Java runtime determines code is eligible for native compilation (frequency of execution is one of the primary parameters), it diverts the execution of the code, so it can perform some fancy hoop-jumping to turn the Java bytecode into platform-specific native instructions, thereby removing any cost of bytecode interpretation, and also throwing some nifty optimizations into the compiled code. From that point forward, the native code will be used for execution, unless and until it has been invalidated by changing assumptions.

JRuby’s JIT compiler is similar in nature, the primary difference being the source and destination formats. In Java the source format is Java bytecode, and the destination format is native machine instructions. Conversely, in JRuby, the source format is the JRuby AST, and the destination format is Java bytecode. Perhaps the most fascinating aspect of the JRuby JIT compiler is that it benefits from both the initial compilation into Java bytecode, and then later, when Java may attempt to translate the JRuby-generated bytecode into native machine instructions. So effectively, it is possible to get a double-JIT on your executing code.

Generating Java bytecode from interpreted Ruby code is no small feat, however; so, without further ado, let’s start the tour of JRuby’s JIT!

Read the rest of this entry »

Danny Carey at Drum Explorers Clinic

October 2nd, 2009

d_careyAs most of my close friends know, while having only recently picked up any form of drum stick, I’m passionate about drumming (though I’m personally still a beginner in my ability to play). One of my favorite modern drummers is Danny Carey; I’m sure in no small part due to Tool being one of my personal favorite bands. Even if I attempt to exclude my bias, however, I can see that Carey is a well-admired drummer, generally somewhere in the top 15 of top-100 drummer lists of all time; sharing space with the likes of Neil Peart, John Bonham, Keith Moon and Mike Portnoy.

Danny Carey has a rare technical accuracy in his playing, but he is able to combine it with his singular artistic flair to create remarkable tapestries of sound. Tool songs are initially accessible to listeners in search of a driving rock sound, but continue to breathe and grow as the complex rhythms unravel over time.

I’m always amazed to pick up an album like Undertow (from 1993) and to this day still hear new  poly-rhythms in the beat and other minor adjustments for the first time. And it only takes listening to a song like Jambi, where the guitar, vocals, and drums are all on entirely different time signatures to be able to understand how capable he really is.

Recently, Danny Carey came into Kansas City for the 25th anniversary of KC Drum Explorers. He gave some tutorials, played along to some particularly drum-intensive Tool songs, and also had some great company: Terry Bozzio (another brilliant drumer) and Aloke Dutta (a wizard of the tabla, and mentor and teacher to both Carey and Bozzio).

I have no idea how I missed hearing of this event; it was mere minutes from my house (in a high-school auditorium in suburban Overland Park of all places), but thankfully YouTube has come to the rescue to make me feel like something other than a total failure.

I’ve dug up some videos of the event, and included them here (thank you evo462, jdub816, and andrewl85). Enjoy! Read the rest of this entry »

Java Application Management With Custom MBeans

September 29th, 2009

beansJava 5 added the ability to work with MXBeans as part of the core Java platform, via the java.lang.management package, and specifically the MBeanServer API. In this article, I’m going to walkthrough of a quick example on how to surface components of your application into the platform MBeanServer so that you can maintain your application with any standard management utility, like VisualVM.
Read the rest of this entry »

Distilling JRuby: Tracking Scope

September 25th, 2009

Ruby LogoOne of the things that is always going on in any programming language is managing the scope of variables. Scope is central to both how we code, as well as how a program executes. Even just in methods, how variables are scoped can be a point of great contention (particularly in code reviews).

When it comes to implementing a programming language like JRuby, the concept of a scope permeates everything. After all, someone needs to track what variables are available at each level in the activation stack, and when the stack unwinds (either through normal use, or due to an exception), someone needs to unbind the variables in scope with it.

And, of course, Ruby has closures, which means that you have to carry (aka capture) free variables into scope of the closure. But, Ruby also has instance and class eval’ed code blocks. Those have an entirely different scope. When you get down to it, Ruby is bound to test a scope algorithm’s limits.

So how does JRuby do it?

Read the rest of this entry »

JRuby 1.4 Plan Details Discussed

September 21st, 2009

Ruby LogoThe JRuby team has posted some key JRuby 1.4 details over at the Engine Yard blog.

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).