Rock Star Neal Ford

Bio: Neal Ford is software architect and meme wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is the designer-developer of applications, instructional materials, magazine articles, courseware, video and DVD presentations, and author or editor of six books. His three sessions at the 2009 JavaOne conference compare JRuby and Groovy, demonstrate how to make unit testing more palatable, and contrast traditional design patterns on the JVM* with the more metaprogramming approach associated with dynamic languages.

Q: What differences between JRuby and Groovy would be most useful for Java developers to understand?

A: Java developers frequently make the mistake of thinking that the two languages are pretty much the same, only with slightly different syntax. However, they exist for two completely different reasons. Groovy provides a modern syntax while remaining true to the semantics of Java. That means that Groovy's interoperability with Java is unparalleled, but it also means that Groovy brings some Java baggage along as well: the way properties work, the syntax for the switch statement, and so on.

JRuby is the Java platform port of Ruby to the Java virtual machine (JVM). Thus, JRuby is a ruby, meaning that it has all the elegance and power of the Ruby language. Because it is free from the Java language, the basic Ruby language tends to be more elegant -- but at the sacrifice of tight Java interoperability.

What does this mean? If you are looking to modernize your syntax and gradually migrate to a more powerful, more expressive language, then Groovy makes good sense: It fits pretty seamlessly into the Java ecosystem, especially something like Grails, which encapsulates the de facto standard Java stack. If you are looking for the most powerful, elegant language on the JVM, and interoperability is less of a concern, JRuby makes perfect sense.

Q: Java Champion Heinz Kabutz remarked that when he gives talks to experienced developers and asks how many of them do unit testing, few raise their hands, something that Kabutz thinks is a big mistake. Java Champion Joshua Bloch echoes Kabutz's feelings. How do you make unit testing more palatable for Java developers?

A: In several ways. First, make developers, and more importantly, managers realize that testing is the engineering rigor of software development. We don't formalize proofs like other engineering disciplines, but we have the advantage of being able to almost instantly construct our materials and make sure they do what we think they should do. Legal ramifications prevent civil engineers from building bridges that they haven't proven safe via engineering disciplines. We should adopt the same attitude in software development. When a manager tells developers to stop writing tests in the interest of time, we should refuse on the grounds that it isn't professional to write software without tests.

Second, when you write code and then write tests, the tests are much harder to write because the code wasn't written with testability in mind. Doing real test-driven development (TDD) ensures that all lines of code have tests because you write the tests before you write the code. Getting into a habit of writing all code TDD is liberating and has lots of beneficial side effects on your code, including improving the design of the code because you can allow the important design elements to emerge as part of the exploratory part of testing.

Third, embrace the increasingly sophisticated tools that make testing suck less -- hey, that would make a good title for a JavaOne presentation! -- tools like Infinitest, Jester, Hamcrest, mocking frameworks like unitils and MockRunner, and a host of other nice tools. Testing doesn't have to be hard or time-consuming in Java if you pick the right tools.

Q: Give us a contrast between the traditional approach of design patterns on the JVM and a more metaprogramming approach associated with dynamic languages.

A: In Design Patterns, there is an implicit bias toward structural solutions to each problem. Every example in the book has an accompanying UML (Unified Modeling Language) diagram. In more powerful languages such as Ruby and Groovy, you can solve the same problems more elegantly by using language facilities like metaprogramming.

For example, the factory design pattern is the result of the fact that C++ -- and thus Java, because its syntax is based on C++ -- uses the class name as the constructor name. That makes it hard to abstract the semantics of what you need from a concrete class. So the Design Pattern, Factory, and AbstractFactory ameliorates this. In JRuby, construction isn't a special case. You simply send the new message to a class -- implementing the Factory pattern is so trivial that it isn't called out as a special thing.

The Design Patterns book was really two things: good definitions for common problems encountered in software and recipes for how to solve these problems. The nomenclature is still very useful and pertinent, but the recipes can be supplanted by using languages that have much more powerful mechanisms, such as metaprogramming, to solve problems without building extraneous structure.

_______
^* As used on this web site, the terms "Java Virtual Machine" and "JVM" mean a virtual machine for the Java platform.

» Neal Ford's Blog and Web Site
» Design Patterns

Neal Ford will be hosting the following sessions this week:
» Comparing Groovy and JRuby (TS-4955)
» Unit Testing That Sucks Less: Small Things Make a Big Difference (TS-4964)
» Design Patterns for Dynamic Languages on the JVM Machine (TS-4961)

Do you have comments about this article? We welcome your participation in our community. Please keep your comments civil and on point. You may optionally provide your email address to be notified of replies - your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.