Ball: I started at Sun in 1994 and have worked with Java technology for 12 years. I joined the JDK team when the Java language was still called Oak, and I created the first debugger API and helped with the AWT (Abstract Window Toolkit) for the 1.0 release. For 1.1, I rewrote the Windows AWT implementation and co-designed the AWT's new event model, which we then extended to create Swing. After a short stint as the tools architect for the application server team, I worked with James Gosling again on the Jackpot Project at Sun Laboratories.
Three years ago, the Jackpot Project members transferred to Sun's Developer Tools Group -- formerly known as the Developer Products Group. There, after a year of integrating javac into the NetBeans IDE, I rewrote Jackpot's research prototype as a set of NetBeans modules. JSC: What was your background before you came to Sun? Ball: Prior to joining Sun, I worked as an operating systems and middleware engineer on the PenPoint operating system at EO, the Patriot Partners project at Metaphor, and on CTOS at Convergent Technologies. Convergent in the mid-1980s was known as the Marine Corps of Silicon Valley because we shipped new hardware, operating systems, and system and networking software to our OEMs on a punishing six- to nine-month schedule. While there, I learned microkernel OS architecture, asynchronous application design for service-based multithreaded distributed systems, MVC (Model-View-Controller) design from Xerox PARC alumni, and object-oriented programming. It was a great engineering team, and I learned more from that apprenticeship than anything taught in colleges back then. I spent my early adult years as a professional musician, which fortunately didn't destroy too many brain cells. JSC: What is the Jackpot Project? Ball: Jackpot is a technology used for searching Java
source code and safely and correctly transforming patterns in code,
while writing minimal changes back to source. It relies heavily on
the new javac API, JSR 199, the Java Compiler API; JSR 269,
Pluggable Annotation Processing API; and the javac Tree API,
Jackpot runs on the Java 2 Platform, Standard Edition 5.0 (J2SE 5.0) or later but supports all source levels. It is not just another refactoring tool. Refactoring tools usually focus on individual changes. Jackpot focuses on projectwide transformations. JSC: The Jackpot Project has added noteworthy reengineering capabilities to the NetBeans IDE. What should developers understand about this? Ball: It's important to understand that Jackpot's "engine" is fully accessible to developers, so it's easy to write your own Java queries and refactorings. I'm a little worried that people will just look at the built-in queries and reengineering commands and not realize that there's a big iceberg under that little tip. I've been catching up on all the great reengineering suggestions in the queue. They are fun to write and don't take much time, so the built-in set of commands will soon be much more compelling. Write Boring Code
JSC: Do you have any tips about writing better code? Ball: The best tip I can offer -- and want to follow more myself -- is to write boring code whenever possible, code that is so obvious it doesn't need comments and that other developers who thrive on cleverness will ignore and dismiss. Write code that does only one thing but does it really well, so you can write it and forget about it while it quietly works in the background. For example, the classfile module in the NetBeans IDE does one thing: read JVM* class files and make them available as classes that are closely based on the JVM spec. You can't modify any of the classes -- they're immutable. It doesn't support class file editing or creation, and none of its classes should be surprising to anyone who is familiar with the JVM specification. Because this module is "boring," no one wants to hack it for fun -- it gets updated only when the JVM spec changes -- so it has been very stable for several years. Being simple, it's very fast, with little memory overhead, and because it's immutable, it's threadsafe. Perhaps most important, because it's stable and boring, I've been able to work on other projects instead of having to maintain and enhance it over the years. I've discovered when reading my own code that if figuring out how it works requires some reflection, the code probably doesn't work as well as it should. That's why I'm such a big fan of refactoring, because its goal is to simplify and clarify code without changing how it operates. In programming as in life, less is more. I've been a big fan of using tools as much as possible, which is why I keep getting sucked back into creating them. For example, the Jackpot Project at Sun Labs didn't start out to create a reengineering tool -- its goal was to engage in lots of small experiments in an effort to increase developer productivity. James Gosling became the chief technical officer of Sun's Developer Products Group, and I joined the NetBeans IDE project because each of our experiments led to the same conclusion: Good tools offer the biggest improvements in developer productivity. Jackpot is less about cool metamodel manipulation and more about removing repetitive coding changes from your task list. So pick a good IDE -- it used to be Emacs, then Visual C++ for me -- and really learn how to use it. Then every week or so, pick up the manual or browse the UI (user interface), find a feature you don't know well, and learn about it. At the same time, keep an eye out for new tools that you might use on the command line or that might even replace your current IDE. Good tools help you to do great work. For example, in spite of having worked on GUI (graphical user interface) toolkits off and on all my career, I hate creating forms and end up spending too much time messing with them. It got so bad that I would clean your house's gutters for you if you'd write a form for me. But then the new Jackpot UI dropped a load of forms on me with little time to implement them, so I had no choice but to use Matisse, the new form editor in NetBeans. It was quite easy to use, and the experience was very rewarding. So you'll have to clean your own gutters from now on. Finally, use the IDE's debugger and profiler regularly -- no print statements, no excuses, just do it. Once you get over the learning curve, knowing how your program really operates will make you a much better programmer. I learned that most of Jackpot's performance problems were caused by premature optimizations. Regardless of how smart they are, no developer really knows how to optimize their programs until they measure them. The Music of Code
JSC: You spent your early adult years as a professional musician. Did that inform or influence you as a developer? Do you see any similarities between coding and playing music? Ball: Absolutely, and it's not just a personal belief. Walk down any software engineering hall and ask each developer what musical background they have. In a creative team, you find that at least a third have some early piano or band experience, and quite a few others grew up being multilingual. Math and written music are both symbolic languages, and they stimulate similar areas of the brain. Not many people know this, but the Java Sound implementation in the JDK was created by a small company led by the musician Thomas Dolby. He claimed that "She Blinded Me With Science," but he was quite able to hold up his end of the engineering conversations when working with JavaSoft. Both writing music and recording it are more like developing software than playing music is. All of these disciplines are crafts -- regardless of the science behind them -- that most people can learn to a certain extent but some people have a gift for. I don't know if code can be beautiful, but it certainly can be very clear. And clarity in any form of writing is to be admired and sought after. Funniest Developer Experience
JSC: What is the funniest thing that has happened to you as a developer? Ball: Well, my sense of humor is skewed, but here goes. When Convergent Technologies (CT) was acquired by Unisys, the engineering team that "enhanced" our OEM product finally got their revenge after years of getting beaten every time they tried to out-engineer us: They became our management. Consequently, most of our star players left, and morale bottomed out. Because I owned the editor, as a small act of defiance, I added an Easter egg to it, which, when triggered by a certain key sequence, would add "CT forever!" to the displayed version string. This brightened everyone's mood, and when the Unisys developers discovered it, they appreciated it for its team-building value. But then a pointy-haired manager caught wind of it and filed a P1 demanding that it be removed. I closed it and suggested that one of their engineers "fix" the issue because they had all the source code. The Unisys engineers studied the source for weeks, while the manager demanded daily updates on the status of the so-called keyboard bug. Finally, my director politely asked if I would fix the keyboard bug because their engineers had given up. I did this and then sent an email to everyone saying that I wasn't trying to inflame tensions between our teams, but that "CT stood for engineering excellence, and so I hope that whenever people search for CT in our products, they'll find it." Case closed. To this day, if you bring up the editor's search-text dialog and
enter A Story From the Oak Days
JSC: As an original member of the Oak team, can you share any war stories about the origins of the Java programming language? Ball: There is a story that I believe is true -- because I
saw its effect the next day -- that had to do with the tech team's
decision that it was too risky, schedule-wise, to add the
checked-exceptions feature that Bill Joy was pushing hard for. Previously,
all exceptions functioned the way James Gosling told me that he included assertions in an early version of the language, but the rest of the team had him delete them because of performance concerns. I can believe it, because it took me weeks to convince the JVM engineers to allow a Boolean test in the interpreter loop to support data breakpoints, and then only if I created it in an alternate interpreter loop that would run with the debug flag. We've always been obsessed with performance. JSC: What are the keys to well-crafted code? Ball: Simple, small classes that are loosely coupled. I don't always achieve this ideal, but it feels really good when I do. JSC: What do you do when you are stumped or just stuck? Ball: Give it time. Usually I'm stuck because I don't fully understand the design or the problem clearly enough yet, and if I give it time to gel, something much better will come out than if I force things. Creating Tools -- The Developer Is the Customer
JSC: What appeals to you about creating tools? Ball: For most software projects, it's important to remember that we developers aren't the customer, that we shouldn't assume that our customers' needs are the same as our own because they aren't developers. With development tools and maybe computer games, developers are the customers! It means that you have a basic understanding of the customers' needs, sometimes better than your marketing or management folks. Plus, the work you do is important to your colleagues, and after all, we all still like to impress each other. JSC: Where do you see Java technology tools going in the next few years? Ball: My crystal ball broke years ago, but what I hope to see is that both frameworks and tools increasingly eliminate all the boilerplate code that wastes so much of our time. The boilerplate may be needed now, but it really hurts productivity. JSC: What has been your biggest surprise in working with the Java programming language? Ball: That it is still a pleasure to work with after 12 years. It's the first language that had the right "heft" for the great majority of the projects I work on. JSC: What do you enjoy most about programming? Ball: Shipping products. A project doesn't seem truly legitimate until it is in the hands of real customers who need it to get real work done. JSC: Do you have a favorite Java technology book? Ball: I don't have a favorite, but lately I've really enjoyed Hardcore Java by Robert Simmons Jr. and Swing Hacks by Josh Marinacci and Chris Adamson. JSC: What recent changes to the language have made your life easier? Ball: It's a small "syntactic sugar" change, but my
favorite new feature is the enhanced JSC: Tell us about your experience of the role of open-source communities in helping to create software. Ball: My first experience with the open-source community was at Metaphor, where we contracted with Cygnus to extend gcc to support garbage collection. I was really impressed with the quality of the work, and the idea of contributing that extension -- as GPL required -- really appealed to me. Joining FirstPerson, the group that grew into JavaSoft, right before the Java alpha released was like coming home, because I was again part of a team that shared its source code with its community. And of course, being a NetBeans IDE team member means first being a contributing member of our community. Advice to New Developers
JSC: What would you say to someone just starting out as a Java developer? Ball: Programming is still a craft, so the more you can work with senior developers, the more you'll learn of the important stuff the computer science professors don't teach. If you have time, join an open-source project and help out in any way you can to learn and to build credibility with your peers. But don't join every project you find interesting. I've seen many enthusiastic newcomers spread themselves too thin, overcommit, and thus not be taken seriously. Finally, get to know the various Java communities through their forums and blogs, then join in. We're a great group! See Also
Tom Ball's Blog
| |||||||||||||||||||
 |
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
