If Java is a steady freight train, then Ruby on Rails is one of the sleek, super-fast Acela trains that whoosh travelers along Amtrak's Northeast Corridor. Java has come under pressure as being unfit for the Web tier because of its complexity, while scripting or dynamic languages such as PHP, Perl and Python continue to gain acceptance because of their ease of use and performance.

At both the EclipseCon and TheServerSide Java Symposium last week, two major Java-oriented events, the mantra seemed to be about how to make Java more like Ruby on Rails. Indeed, due to the complexity of Java and the Java Enterprise Edition platform, several Java development framework projects sprang up to provide Java developers with lighter-weight, simpler-to-use options, including RIFE, Seam, Spring, Tapestry and Trails, among others.

However, the non-Java Ruby on Rails, which is based on the Ruby dynamic language, has posed perhaps the biggest threat to Java development on the Web tier. And perhaps the biggest Java "pressure-izer," said David Heinemeier Hansson, the creator of Ruby on Rails.

"I think the dynamic languages are posing the greatest threat that Java has yet to face," Heinemeier Hansson said. "Microsoft's C# was more of the same and from a closed-source company at that. Lots of reasons to ignore. The dynamic languages, and perhaps Ruby on Rails in particular, are a faster, better and free way for a huge chunk of possible applications."

There is little doubt the Java world is feeling the pressure from dynamic languages. Java's creator, James Gosling, cites a flamefest he incited by simply defending his position regarding dynamic languages. And at TSSJS, a panel of Java experts spent the better part of their discussion on how Java is taking it on the chin from dynamic languages.

"I think Rails is making the dynamic story too hard to ignore," Heinemeier Hansson said. "With Perl and PHP, it was easy to ignore. Sure they got stuff done fast, but they also (allegedly) produced unmaintainable code. So the Java guys could lean back with content thinking that the complexities of their stacks were simple, inherent to solving substantial problems with maintainable code."