Summary
The Ruby on Rails way is starting to influence thinkers in Java. Matt Raible apologizes on behalf of J2EE on how silly it looks to do CRUD in AppFuse and Trails has been announced as an approximation of Rails with Java frameworks.
Advertisement
Ruby on Rails is stirring up the waters in the Java world. Matt Raible, the man behind AppFuse (kickstarting J2EE development), has been "thinking about Rails ever since I wrote a post about it".
The thoughts must have lead to some frustration with his current environment, though. Here's his description of why doing a CRUD on a single database table would flunk any productivity test:
...if I did it right now in AppFuse's current state, it'd be a disaster... To CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long!
While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized.
Compare this to the Rails approach:
class Post < ActiveRecord::Base
# All attributes are given accessors
# through column introspection
end
class WeblogController < ActionController::Base
# The controller now has actions for all
# CRUD operations and uses introspection
# to select the input fields and columns
scaffold :post
end
I'd be depressed too if my environment forced me to go through a 20 minute setup phase (and that's for an expert, I'm sure creating and updating 16 files could easily take longer for people less skilled than Matt).
Naturally, this has spawned interest in remedying the situation for Java. Enter Trails by Chris Nelson:
The Trails framework is a domain driven development framework inspired by others that have gone before it such as Rails and Naked Objects. Its goal is to make developing database-driven web applications in Java radically easier, faster, and more fun. The basic approach is to eliminate as many of the steps as we can.
While I laud the aspirations for easing the pain that is J2EE, I'd advice treating the disease rather than the symptoms. Which is of course while I keep stressing the use of Ruby on Rails instead of just Rails. Rails cannot happen in a language like Java. Approximations will try, though.
But if you're stuck with J2EE as a fear-driven technology choice made by higher powers, I most certainly recommend checking out Trails. Chris is picking thebestinfrastructure J2EE has to offer and will attempt to make it fit like Rails. That's a great starting point and a good vision. Best of luck!
Much as I love Ruby, I'm glad to hear that people have been inspired to bring some of the goodness of Rails to the Java world as well. Like it or not, there are a lot of doors that are closed to Ruby but open to Java. And who knows, perhaps Trails will take off in a big way, and raise the profile of Ruby among Java developers.
Also, while Java may be slower to write and less expressive than Ruby, let's not pretend it doesn't also have real benefits for many projects and teams. It's not entirely the language's fault that Java frameworks (in general) make life so much more difficult than they need to. I blame the mindset, so common in the Java world, that ease of use or speed of development is not something a platform or framework needs to worry about; that "tool vendors" will fill in the gap with wizards and drag-and-drop front-ends. But as all of us down in the trenches can tell you, way too often the gap never gets filled and thousands of beleaguered developers are forced to copy and paste XML config files and whatnot, all in the name of flexibility and indirection that is almost never taken advantage of.
Trails sounds like a big step in the right direction, even if it never reaches the convenience and elegance of Rails.