Technologies to Watch: A Look at Four That May Challenge Javas Development Dominance

Bruce Tate has an amazing track record when it comes to identifying successful technologies. He was one of the early developers that identified the emergence of the Spring framework; he predicted the demise of EJB 2 technologies a full year before the EJB 3 expert group abandoned the older approaches. In his new book Beyond Java, Bruce looks at languages and technologies that may challenge Java's dominance in some development niches. In this article, Bruce covers four important emerging technologies.

Java has been an outstanding development language for the industry because it's brought a remarkable unity and attention to important standards where practically none existed before. But like all programming languages, Java will too fade in time. As I did my research for Beyond Java, one recurring theme was that a growing number of people just don't believe Java is productive enough anymore. This set of technologies can help make you much more productive. They're not suitable for every project, but they are excellent tools when applied to the right problem.

1. Dynamic Languages

Dynamic languages can be much more productive than static ones like C++ or Java. They allow you to express more with less. Here, I'll focus on Ruby, the hottest emerging dynamic language right now. Compare "Hello, World" in Ruby versus Java:

puts "Hello, world."

It's simple and concise. You don't have to write anything beyond the code that does the job. And the Java counterpart:

With Java, types are static. That means the compiler checks all types; you must create and compile a full program. With Ruby, types are dynamic, so you don't have to declare them. You can just start typing and go. Here's a Fibonacci sequence in both languages.

First, Ruby:

x1, x2 = 0, 1
10.times do
puts x2
x1, x2 = x2, x1+x2
end

Notice the parallel assignment in the first and fourth lines, letting you concisely express two different assignments. Also, notice that 10 is an object, and it supports methods, like times. Also, between do and end, you have a code block. Ruby code blocks let you pass fragments of code to a method. This technique leads to incredibly productive and concise code.

You need to declare every variable, and spell out your iteration with the for loop. Each assignment is independent, so you must have a temporary holding variable for total.

So the dynamic languages are more concise. As a general rule, if you can write less code without sacrificing readability, less code leads to greater productivity. (But you can't sacrifice readability to get there, our you wind up with Perl, for example.)

More importantly, dynamic languages are better at important problems that Java developers want to solve, like metaprogramming. Hibernate uses metaprogramming techniques to make objects persistent. Spring uses metaprogramming to add services to Java objects without you having to build explicit support for them. The exploding Ruby on Rails framework takes good advantage of the capabilities in Ruby to build one of the most productive application development frameworks in existence.

The list of Java developers adopting Ruby is astounding. Ant and Tomcat inventor James Duncan Davidson is working on Ruby on Rails, and one of the bestselling Java authors and JSF (Java Server Faces) expert group member David Geary is writing a book on Ruby on Rails. Dozens of the brightest minds in the Java community are moving to more dynamic languages like Ruby because the newer languages better solve the most interesting problems. Dynamic languages will not completely replace Java, but they will be more attractive for small, lightweight problems.

2. Continuation Servers

Web programming is an absolute disaster. After ten years of Java programming, we still haven't built a framework to get the Back button right. Web applications are stateless, so web applications scale better. But stateless applications are hard to build, and our frameworks do not give us much help. With most Java web frameworks, you basically build many unrelated pieces of the application using servlets or JSP, and then wire them together by manually saving objects that you need in temporary storage objects called sessions.

Continuations are language constructs that let you quickly store the state of a thread, and execute that thread later. Continuation-based web frameworks generally make web development much easier by simulating a stateful application. The framework uses continuations to automatically save the state of an application when your application needs to get data from the user. The application can also reload a continuation if the user presses the Back button or goes back to an older page in the browser history.

The best continuation-based frameworks are developed in dynamic languages. By far, the most robust is Seaside. It's a framework based on Squeak, a Smalltalk dialect. Seaside features fantastic debugging support--you can actually inspect, debug, and change your code from a browser. Borges, Iowa, and Wee are Ruby-based frameworks supporting continuations.

Java does not support continuations, but several Java frameworks build in special limited support to simulate continuations. These frameworks have some of the characteristics of continuation frameworks in other languages:

Spring Webflow uses a state engine to provide good Back button support, and also some of the other features of continuation servers.

Lakeshore uses suspended threads to simulate continuations. This approach is not as scalable as some of the others, and lacks full Back button support, but it has promise.

Others emerge almost monthly. I believe we'll all be using web development frameworks that support the continuations-based approach, in one language or another, within three years.

3. Convention Over Configuration

Java developers often look for ways to improve configuration. Newer frameworks are increasingly using Java 5 annotations to do configuration. Other frameworks are using a different approach. Ruby on Rails often uses conventions to infer relationships that require configuration in other frameworks. For example, a Rails controller called BlogController with a method called show, upon completion, will automatically render a view called show.rhtml in the blog_controller directory. Rails also uses naming conventions to tie persistent classes to database tables. By default, a class called Person will map to a table with the English plural: people.

Newer frameworks will favor convention over configuration.

4. Metaprogramming

As alluded to earlier, there's been a whole lot of hype around the Ruby on Rails programming framework. I think the hype is justified. Ruby on Rails lets you program at a much higher abstraction than you do in languages like Java. With Ruby on Rails, you can create domain objects that discover the contents of a relational database table. For example, you could have this simple model object:

class Person < ActiveRecord::Base
end

This class is fairly limited on the surface, but once you execute it, Rails works its magic. The Active Record framework (which implements persistence for Rails) goes out to the relational database, scans the system tables for the table definition, and discovers the columns in the database. Active Record then adds an attribute to the class for each column in the database, and adds a unique identifier to the class, from the database column named id. You can use the above class to write this code:

The database columns and behaviors are all added to the Person class at runtime. You can also extend Person easily:

class Person < ActiveRecord::Base
has_many :cars
end

Through a simple Ruby method called belongs_to with the symbol :department, I've done all that I need. Under the covers, Active Record uses Ruby's metaprogramming to add all of the methods and instance variables needed to manage a one-to-many relationship between a person and a department. The Rails users get a domain language for managing relationships like inheritance, and can use Ruby to work at a higher level of abstraction. Rails seamlessly extends the Ruby language.

Is Rails the next great framework? Possibly. Alternatively, Rails could be just the first in a wave of metaprogramming frameworks in Ruby and other dynamic languages. Or you might see Rails as the backbone for several loosely aligned technologies, built with a metaprogramming foundation. In any case, you'll be much more productive.

Conclusion

In Beyond Java, I make the case that Java's not dead yet, but for the first time in nearly a decade, we're seeing compelling innovation happen beyond the borders of Java. These four technologies will play an important role in the near future. Watch them closely.