Rock Star David Holmes

Bio: David Holmes is a senior Java technologist at Sun Microsystems who focuses on concurrency, synchronization support, and real-time programming. He is a member of both the technical interpretation committee for JSR 1, the Real-Time Specification for Java 1.0 (RTSJ), and of the JCP Expert Group for JSR 282, which is defining RTSJ 1.1. This past member of the Expert Group for JSR 166, Concurrency Utilities, is a contributing author to the book Java Concurrency in Practice by Brian Goetz and others, and a coauthor of The Java Programming Language with Ken Arnold and James Gosling. Prior to joining Sun Microsystems, he worked on a research virtual machine (VM) that implemented parts of the RTSJ. He completed his Ph.D. at Macquarie University, Sydney, in 1999, in the area of synchronization within object-oriented systems.

Q: How do you feel about the open sourcing of the Java platform?

A: I think it is terrific. I wish it could have happened a few years ago.

Q: What are the biggest misconceptions you encounter about concurrent Java programming?

I don't think I really encounter misconceptions as such. It's more about expanding people's knowledge about how threading and synchronization works -- and how they need to think about concurrent programming.

Q: How do you respond to the complaint that concurrent Java programming is harder than sequential coding?

A: Concurrent programming is harder than sequential programming -- that's a simple fact.

But if you're starting a new project, design guidelines help you structure the application: Identify the tasks, identify the objects shared between tasks, and the communication that occurs between tasks. If you are retrofitting concurrency to an existing application, then it can be much harder, as there are often subtle interdependencies that aren't immediately obvious.

But the key is to be forearmed with the knowledge and understanding of concurrent design principles, how threading and synchronization work, and what tools are available in the libraries -- such as the java.util.concurrent package.

Get a good book on the subject - such as Brian Goetz's Java Concurrency in Practice. As a contributing author, I may be biased, but it really is a good book.

Q: What are some current uses for RTSJ?

A: In simple terms, the RTSJ might be relevant anywhere that you need to prioritize activities in your application. This ranges from the traditional real-time environments of command-and-control systems, avionics and telecommunications, to the new areas of finance or trading systems and other business services.

Q: If you let your imagination run free, where might RTSJ be found in the future?

A: Absolutely anywhere! From your phone to your car to your bank.

Q: What are the biggest misconceptions that you encounter about RTSJ?

A: The biggest misconception is that real time means "real fast." It doesn't.

Real time is all about predictability -- getting more deterministic response from your program. Of course, the faster the program responds and executes, the better. But in general, what makes a system "real fast" tends to introduce far too much variability for real-time systems. So there's a trade-off.

Q: What online resources do you use to keep up with Java technology?

A: To see what's up-and-coming, I keep track of the Java Specification Requests (JSRs) that are submitted to the Java Community Process (JCP) program at jcp.org.

Q: What advice would you give to a programmer new to the Java language?

A: Take some time to learn the features of the language. Get a good introductory book or two. Don't just try and read the javadocs!

Q: The Java class that you couldn't live without is...?

A: java.lang.Thread -- obviously!

Q: Favorite Java technology book?

A: Doug Lea's Concurrent Programming in Java. That's where I began with Java technology.

Q: Favorite obscure Java feature?

A: Well, I hope people don't find anything in Java technology really obscure, but I suppose the memory model is the hardest thing to understand, yet extremely important from a concurrent programming perspective.

Q: What do you do when you feel stumped?

A: Send email to the extremely bright people I work with. Someone always has a different perspective on something that can back me out of a corner. Often, just explaining things in the email leads to either an "Aha!" moment or a "Duh! I shouldn't have done that" realization.

Q: What's the next big technology revolution?

A: I wish I knew. I'd buy the stock now.

Q: What recent changes to the platform have made your life easier?

A: The introduction of the java.util.concurrent package made things a lot easier for me. Now, instead of trying to teach people how to create synchronization tools, I only teach them how to use them.

Q: Where in the process of programming do you have the most fun?

A: I like to debug for fun -- it's a great challenge. I don't mean ironing out the bugs in code I'm writing, but rather, when external bug reports come in, and I get to explore another part of the system. It greatly helps expand your knowledge of the code base.