Ted Neward Q&A: What you must know about JavaScript, Scala and more

What's your definition of a pragmatic architecture?
Ted Neward: A lot of times "architecture" is used to describe what happens when all of our Web servers are hooked together in a gigantic ESB, [for example]. That, for many projects, is so far down road. A lot of companies are looking to create a Web service to enable two different components or systems to communicate with one another, and there's an architectural element there, but there are a lot of things you can talk about at a more tactical level rather than a grand strategic level. What I'm trying to do is give people a manual of tactics for architecting a project or a couple of closely related projects … to create almost a periodic table of elements for software—so within a software architecture what are the major parts? In the early day of Web services [people] ended up building these subscriber systems where any component can ask for updates, but as the number of subscribers went up, the amount of time to do notification went up, as opposed to a more broadcast-style transport. These are the kinds of things I want people to think about, and say "OK, for the next project I need to build a component that does this, and here are some of the elements involved," and that should drive the direction the architecture should go.

You're also going to talk about ECMAScript, more commonly referred to as JavaScript —what should developers know about that?
Neward: It turns out that the JavaScript language, the ECMAScript language, is not just some bastardized rip-off of Java. You can do some interesting and amazing things if you recognize that it's a real language. One thing is, it has first-class support for functions. The other thing is JavaScript is a totally dynamic language. [For example,] I can change the behavior of a library that ships with ECMAScript to give it new functionality or to change the functionality if I don't like the way it's working; this represents huge power. In many respects these are the things that got people excited about Ruby, but JavaScipt has been able to do it for longer than Ruby's been around—people just don't know it.

There are two main advantages. A lot of Ajax frameworks are written in a style that takes advantage of ECMAScript/JavaScript in this way; and as a result, if you want to figure out what this bit of code is doing, understanding that it's in a functional dynamic mindset will make things more clear; it's like trying to understand Java code without understanding object orientation. The other thing, Java 6 ships with an implementation of ECMAScript as part of the core library, an implementation called Rhino. So we actually have an opportunity to use this language in a variety of ways beyond just the browser. JavaScript is not just about the browser, it's another programming language that has full access to the JVM. It's about time developers started to exploit that.

What do Java programmers need to know about a new programming language called Scala?
Neward: Scala is an important language from two perspectives. Number one, it represents some new ideas that a lot programmers haven't seen, which is to say, how do I program in the functional mindset, how do I program with functions as first-class citizens. In that respect alone Scala will change your mind, to give you some new models for abstraction to make your system easier to understand fundamentally.

The other thing is Scala represents what I consider to be a generational advance in terms of programming language approach and syntax. There are a lot of things I can do with the Scala language that I really can't do with the Java language, and certainly not easily. A lot of people criticize Scala for being far too complex, but a lot of what they're criticizing as being complex is not really baked into language—it's essentially the library that makes up the Scala experience. If you don't like that library, write your own! What has made Lisp so powerful over the years is it starts with very core key primitives and it says build whatever constructs you want on top of those primitives, and people have done so successfully for going on 50 years; Scala borrows a lot of those ideas.

What are the most significant one or two things that happened in the Java community last year?
Neward: The Oracle acquisition of Sun is by far and away most important. That is potentially the comet plunging into the planet's surface, and I don't mean that as a disaster scenario. In many respects [Sun was] a little too focused on the community part and not enough on how do we make money and make sure this environment remains a viable environment. The Java community has gotten spoiled by the idea that everything should be free. Oracle is not going to fly with that. They're willing to give stuff away as long as they can find a way to make money. Oracle will make sure they commoditize Java, in some cases at the expense of the community, and that's not necessarily a bad thing. I think Oracle can be very good, but we'll have to see.

The second most important thing is the invokedynamic JSR. This was a JSR Sun started many years ago; it's slated to ship as part of Java 7. This legitimized the idea that running something other than a Java source compiled code on top of the JVM was acceptable and encouraged. More importantly, invokedynamic is going to give us some low-level features to make it better for alternative languages on top of the Java Virtual Machine, and that's huge. Frankly, Java the language is starting to show its age. The legacy of Java won't be the language; it will be the Java Virtual Machine and the surrounding libraries and ecosystem that have grown up around them. Java is the Cobol of the 21st century, and that's not a bad thing, just a thing.

What development trends are you watching for this year?
Neward: For years the small device market has been saying this will be the year, and Java has always been at the center of that because it was designed for small devices. I think this will be the year where we see a lot of mobile innovation, but ironically I don't think we'll see it in the Java space. I think the Java mobile community—Android and what not—will be doing a tremendous amount to catch up with some of the things that have been going on in the iPhone space. But Google in particular has some things they need to do; they need to make it more consistent in terms of releases and when they're coming. At a certain point Google will have to think of this as a business rather than what happens when engineers run wild. Android may be the platform that forces them to start thinking about this as a business rather than just an engineering problem.