KM: What are your thoughts about Rails, and do you have a favorite
CM: It's interesting that you would ask this one ... I've
been spending quite a bit of time looking at Rails, and other application architectures
based on scripting languages, over the last few months.
About Rails in particular:
- I'm a big fan of the distributed view controller architectural approach,
so I'm liking that aspect of Rails quite a lot.
- Convention over configuration has already been a powerful influence on
thinking in the Java world, because it really does improve productivity. Rails
leverages this idea all over the framework.
- Rails can do a lot of its magic by leveraging the capabilities of Ruby
as a language—such as injecting the data of a controller into the view
so that it can be accessed directly, instead of having to use binding expressions
of some sort. That translates to not only less code in your applications,
but also less conceptual weight on the developer having to remember to keep
changes synchronized. That's going to be difficult to emulate in a strongly
typed language like Java.
- Don't believe the people who tell you Rails is just a toy, based on the
fact that the 15-minute demos just use the scaffolding. You really can build
sophisticated apps pretty quickly. As the name implies, the scaffolding is
there to help you during construction, and is typically not a part of the
- Don't believe the people who tell you Rails cannot deal with application
maintenance over time, including things like database schema changes. The
support for this is well thought out, especially in 1.2's migrations. And,
the fact that you don't have to explicitly modify your model classes is quite
- Don't believe people who tell you that Rails stops being effective when
your database schema doesn't match Rails conventions. They can be overridden.
At worst, you have to go implement explicit properties, which ends up looking
like what you *always* have to use with ORM layers like JPA or Hibernate.
- All of the above being said, Rails has quirks and things you need to get
used to. As DHH likes to say, Rails is opinionated ... if you're going to
use it, going with the flow is going to save you lots of frustration. (The
closest analogy I can think of in the Java world is how Maven is pretty opinionated
about how project builds should work; it lets you do things differently, at
the cost of having to continually tell Maven about it).
- In addition, there are some aspects of large scale applications that are
not (yet?) addressed in Rails (robust support for localization, multiple database
coordinated transactions, and so on). But I wish the Java world had more deployment
support solutions like Capistrano, to better manage (say) 100 instances of
my application in an automated way.
From a language favorite point of view, I've resisted scripting languages for
a long time—I liked the comfort zone of strong typing, and getting help
from the compiler in catching potential mistakes (plus niceties like code completion
in tools). I also really like objects, so things like Java are appealing to
me. That being said, the productivity gains you can get from using a scripting
language correctly are impressive.
PHP, I still shudder too much at how it tends to get (mis)used, although clearly
... love the flexibility, hate the debugging environment on the client :-).
But the flexibility has a down side, too—when you can play games with
prototypes and change the fundamental nature of Object, I start to shudder again.
Of the languages I have looked at, Ruby seems to capture a nice balance between
flexibility and object orientation. The syntax is pretty quirky, and you can
still do some "black magic" things that can mess you up, but it's
much more constrained ... and it's easy to do the right things.
KM: What about Groovy and Grails?
CM: I haven't spent as much time on Groovy. The last time
I looked at it seriously, they went and changed a bunch of the syntax :-). Now
that the language is settling down some, it's definitely time to take a look
Groovy, since it runs on the VM, will have a nice capability to integrate with
existing Java based server side functionality. This will be attractive to Java
developers looking for a lighter weight way to build web front ends for application
environments with sophisticated needs that Rails and similar frameworks (including
Grails) don't yet support. I'm just not sure how attractive Groovy will be outside
the existing Java developer base—yes, there are lots of Java developers,
but there's a lot using other languages too. Will enough of them know Groovy
even exists to make it a viable choice? Time will tell.
KM: So, would you say that Sun is focusing more on non-Java audiences
CM: I would say we're adding additional audiences as targets. We've
had really solid support for Java developers for quite a while (including, for
example, the support for Java EE 5's new features in NetBeans 5.5), and we'll
continue to improve that support in NetBeans 6, most notably in areas like the
text editor, which is dramatically improving.
At the same time, there is an opportunity to make NetBeans an attractive developer
platform for people who like technologies in addition to (or even instead of)
Java. The fact that existing developers need to be fluent in additional technologies
and the advent of scripting languages hosted on the VM lets us offer some compelling
benefits to those developers, such as access to business logic already coded
KM: How do you think all of these projects will influence Sun's tooling
over the next year?
CM: One of the obvious lessons for Sun is that not all important
languages have a name starting with "J" and ending in "a"
:-). So, in addition to improving our support for Java development (the new
editor in NetBeans 6 milestones is *way* better than what we've had before),
we are going to be adding support for several popular scripting languages. The
initial version of support for Ruby (and Rails) just showed up in the latest
milestone, and has really been getting positive attention when we show it around
to existing Ruby developers. You'll see similar improvements in editing and
see improving support for that as well, plus support for technologies like jMaki
One interesting opportunity centers around languages that can run on top of
the VM in the server, since such languages can typically call directly into
Java objects. This enables a class of hybrid language applications, where the
front end can be quickly built and maintained with a scripting language (for
logic and persistence tiers that might already be built in Java.