 |
|
Bio: Tor Norbye is a principal engineer at Sun Microsystems, where he has worked on development tools since 1996, most recently on the Ruby and JavaScript editors in the NetBeans IDE. He is also a cohost of the weekly Java Posse podcast and specification lead for Java Specification Request (JSR) 273. As a JavaOne rock star, he lives the lifestyle by ending each and every programming session with a five-minute keyboard-smashing ceremony before storming offstage.
|
Q: Can you describe the process of writing code?
A: When I'm writing code, it's typically to implement some new feature, and my approach is to first bang out the basic skeleton, and then incrementally fill in the gaps, testing manually by executing the code as I go along. Once I have something basic working, I write some unit tests. When the basic tests are passing, I start worrying about corner cases. I approach these by thinking of every possible corner case and add unit tests for these. I then use these unit tests to hunt down bugs in the code. Therefore, my approach is to code the functionality first, then test later, and then to turn the process around and write tests for cases I don't expect to pass yet, and use the tests to complete the code.
Another important piece of the coding experience is "listening" to music. In iTunes, I have a dedicated playlist named "Coding Music." Coding music helps me tune out distracting background noises and makes the whole experience more enjoyable. The trick is to find music that is not distracting -- which is why I put "listening" in quotes earlier.
Classical music works well, especially baroque music, but also fast dance-oriented music like Madonna's "Confessions on a Dance Floor." I don't always have the luxury of coding with music -- for example, during meetings or podcasts, I've got to look like I'm paying attention. Just kidding. I don't do that. OK, I do. But not always.
Writing new code from scratch is fun, but it's only 90% of the job. The other 90% is making the code presentable and correct. Debugging code is pretty different from cranking out new code. It typically involves spending a lot of time in the debugger, testing out hypotheses, sometimes writing some custom code to narrow down the problem space. However, I actually enjoy debugging as well. I spent my first five years at Sun working on our C/C++ debugger, Sun WorkShop, where I got to not only learn all the tips and tricks of our debugger but also add support for new debugging features. I'll always have a soft spot for debuggers.
Most Important Java API Five Years From Now
Q: What do you see as the most important Java API in five years?
A: @Annotation.
I'm a huge fan of static analysis. With static typing, javac can find lots of problems in the code, so type errors are rare in Java code. But type errors are only part of the problem. Is null a valid parameter to a given method? Can the method return null? Is a class intended to be immutable?
In the bad old days, people would write additional important information about a method as part of the javadoc for that method. And if there's one thing engineers are notorious for, it's opening the box, throwing the instruction manual aside, and starting assembling directly. Consequently, warnings or instructions in the javadoc are not always followed -- and as the code evolves, the comments often don't get updated.
Annotations offer a solution to this. Rather than describing in English -- or whatever language you write your comments in -- that a particular method can return null, add an annotation which expresses that fact. IDEs and static-analysis tools like findbugs can use these annotations to hunt down bug patterns that are difficult to spot with the naked eye. By tracking assignments and return-value-nullability in your code, they can, for example, figure out whether it's possible that you will end up bombing out with a NullPointerException.
And this isn't just limited to null-handling. Additional annotations are on the way to describe, for example, constraints, such that you can state that integers must fall in a certain range, strings must be non-empty, and so on. All of these can be used by tools to not only find bugs but even implement behavior for you. A web framework, for example, can add automatic validation of user entry into a text field that corresponds to an object that it has constraint annotations for.
With annotations, we'll be able to add important modifiers to the Java platform without changing the language. There are a lot of possibilities here, and I think we've only seen the start.
The NetBeans IDE Pipeline
Q: Give us an update on NetBeans IDE 6.1 and tell us what's in the pipeline.
A: NetBeans 6.1 is out, and I think it's a mandatory upgrade for everyone. The previous version, 6.0, was mostly a new feature release, whereas 6.1 is a performance and stability release. That doesn't mean there aren't new features, of course.
Personally, I worked on the JavaScript editing support, which is now on a par with the Ruby editing support. In fact, some of the type inference I added for JavaScript goes beyond what we have for Ruby, so after JavaOne I'd like to go back and try to apply some of the same principles to the Ruby type-inference engine. In addition, there's a team working on a client-side JavaScript debugger, which means you get to debug your JavaScript code while it's running in a browser. We're demo'ing that at JavaOne, and the bits are made available as well -- though this is not part of NetBeans 6.1.
For the upcoming releases, we're planning improved support for our various languages -- Java, Ruby, JavaScript, and so on -- and in addition, top-notch support for more languages. We're about to release a preview of PHP support, and there are several other languages in the pipeline.
Q: The Java class that you couldn't live without is...?
A: There are many, but I wasn't sure which class would be The One, so I decided to tabulate it by going to a source tree I had been working on recently, and see for myself:
% find . -name "*.java" | xargs grep --no-filename "^import java" | sort | uniq -c | sort -r | head
121 import java.util.List;
87 import java.util.Set;
76 import java.util.Collections;
75 import java.util.ArrayList;
63 import java.util.Map;
61 import java.io.IOException;
58 import javax.swing.text.BadLocationException;
43 import javax.swing.text.Document;
42 import java.util.prefs.Preferences;
41 import java.util.HashMap;
So it's clearly the Java Collections, with lists being slightly more important than sets. This obviously only counts classes in the standard Java libraries. When I change the search to look for all import statements, then a number of classes in the NetBeans API surface, since all the code that I write are NetBeans plug-ins.
By the way, I ran that command on the entire NetBeans code base too, and java.util.List came out as number one there as well!
Q: What recent changes to the platform have made your life easier?
A: As is evident from the previous answer, I rely heavily on the Collections API, and the Java 5 generics and enhanced for loop have made using them a lot more pleasant.
Advice for Beginners
Q: What advice would you give to a programmer new to the Java language?
A: Three things.
One: Learn to use your tools. And I don't mean just enough to get by. I mean really learn how to use your tools. Become an expert user. After you've learned all the items in menus and context menus, and after you've learned the most important key bindings, Google tips and tricks for your IDE.
Learn how to use built-in code templates. Learn how to use the quickfixes. For example, in NetBeans, you don't have to write the left-hand side in assignments when you're calling a method. Just write this:
"foo".indexOf("o");
Move the caret inside indexOf, the method name, and type Alt-Enter. Assuming you're calling a method that has a return value, and you're not already reading the return value, NetBeans will generate the left-hand side of the assignment -- including the type declaration -- for you:
String indexOf = "foo".indexOf("o");
At this point, you're in code-template-editing mode, so you can type a new name for the result variable.
Similarly in NetBeans, try typing newo and hit Tab. Go ahead. Try it.
And that's just the editor. You also need to know how to properly use the debugger, profiler, and version-control integration.
Two: Learn how to make trade-offs. When you're a computer science student, you typically have programming assignments where the inputs and outputs are pretty clear, and the scope is limited. You can write a "perfect" program that's well documented, elegant, fully tested, and correct. In the software industry, that's often not the case. There's a never-ending list of requests. You've often taken over somebody else's code, and you're not thrilled with the way it was written.
Then, at least for mature products, there's also a pretty large number of low-priority bugs -- bugs that are real but of limited impact, so they didn't hold up the last release. What is more important: Add a feature that will benefit a lot of users, or fix a bug that affects almost nobody? Rewrite the code to make it more maintainable, something most programmers long to do? Spend time helping users of the current shipping version of the software? There aren't enough resources to do everything, but they're all important. So you end up having to time-slice to address at least some of these, and in addition, make hard choices.
And even if you have perfect time-management skills, or your manager makes priority choices for you, at the end of the day, as an engineer, the software discipline is also filled with trade-off choices. To speed up some code, you can make it faster by adding a cache -- but that drives up memory consumption. Is that trade-off worthwhile? Congratulations, it's your job to answer that one.
Three: Finally, learn the platform APIs. There's a huge number of well-written and performant classes in the Java platform, along with some utility classes around them. Make sure you have a good grasp of all the available functionality in the platform before you write your own code. For example, yes, there's no reverse() method on the java.util.List interface. But not so fast -- don't write it yourself, there's a Collections class which contains a lot of utility methods that operate on collections like List, and it provides a reverse() method.
And if you're building on top of a rich-client platform like NetBeans, or using other libraries like the Google Collections API or some of the Apache libraries, there's a wealth of additional APIs you can reuse. For example, when I write my unit tests for NetBeans code, I can rely upon additional testing infrastructure written for NetBeans that make it simple to add performance-related tests or memory leak tests.
The Java Posse
Q: You are a member of the Java Posse, which offers podcasts and other information on Java. Where did the idea come from?
A: Dick Wall had the first Java podcast that I know of a couple of years ago, named The JavaCast. I was one of the first interview subjects on that podcast, for my work on Project Rave, the visual web designer in NetBeans. For various reasons, that podcast fell apart, and Dick set out to find a new cohost and approached me. Along with Carl Quinn at Google and Joe Nuxoll at Apple, who had both worked with me at Sun, we started the Java Posse.
Basically, we're good friends, and we like to get together and talk about Java and the tech industry. Recording our sessions has turned out to be a great idea. It has opened doors such that we can interview Java technology luminaries, where we get to ask the really technical questions, since most other publications tend to stay high level.
It has also provided us with a whole community of interesting conversations -- our Google newsgroup is active, and we also have an IRC channel, a Facebook group, and an annual conference in snowy Colorado! We've hosted the Java Posse Roundup two years in a row now, and spending a week in a fantastic winter resort, with mornings in an open conference-style technology discussion, afternoons skiing on the mountain, and evenings hanging out with other engineers, is both a fantastic vacation as well as an extremely educational experience.
Q: Is there an intellectual discipline or fun activity that you feel makes you a better developer?
A: Well, yes -- developing software.
Seriously though, the most important part about being a good developer -- or a good shoemaker or a good farmer for that matter -- is enjoying what you do. I enjoy writing code. I'm very lucky that I've been able to make a career out of it, since I believe I'd do it in my spare time even if my job was something else.
Outside of software development, I've always been interested in music, playing various instruments as a kid, and messing around with a synthesizer and recording software in my spare time since then. This is not scientific, but it seems to me that a pretty large number of good developers have some kind of affinity with music. Perhaps it's a coincidence, perhaps it's just a wrong impression, but perhaps there's something to it.
Music consists of patterns, and listening to music is pattern recognition. Music also involves logical progressions -- and sometimes unexpected or "illogical" creativity, combining elements from many other melodies and so on. This isn't my own theory; I heard somebody else suggest it, I don't remember who, but it may have been Tom Ball. It fits my own experience.
Q: What's the next big technology revolution?
A: Hopefully something related to our numerous environmental problems and challenges -- reducing carbon emissions, reducing garbage production, technology to clean up consumer and industrial waste, improvements in efficiency, or reduction in cost of solar, wind, and wave energy, and so on. We can't seem to get our act together financially or politically to tackle these problems, so perhaps a technology revolution will help speed things along.
Q: If you could work on a dream project, what would it be?
A: This may be a cliché, but I already do! As a programmer, I don't think there's anything more rewarding than working on programmer tools. As the infamous hair club ad said, "I'm not just the president, I'm also a client."
I'm not just a developer, I'm also a user of the software I work on. That means I'm constantly thinking of new features I'd like to use -- and then it's my job to go in and add them. Whenever I find something annoying, or when I think of a way we could make the tool even better, I can either fix it myself since I know the code base, or use my contact list to get others on the team to fix it.
For More Information
Tor Norbye's Blog
Tor Norbye will be hosting the following sessions this week:
- The NetBeans Ruby IDE: You Thought Rails Development Was Fun Before (TS-5249)
With Brian Leonard of Sun
- Meet the Java Posse (BOF-5998)
With Dick Wall of Google
|
