An Interview with Richard Monson-Haefel
JDJ's Alan Williamson caught up with the well-known Java luminary Richard Monson-Haefel just after his recent appointment to the JCP Executive Committee. Alan asked Richard a broad range of questions including his view on how Java as a language has matured and what we are likely to see in the next year.
JDJ: Thank you, Richard, for taking the time to talk to JDJ. I believe congratulations are in order: election to the JCP Executive Committee. How do you feel about that? Did you have to lobby for support?
RMH: I'm honored to serve on the Executive Committee, and I didn't do any lobbying for it. I think some of the JCP members figured another individual (as opposed to a corporation) might add something to the process - Doug Lea has served as an individual on the EC for a couple years now and was voted back in by a landslide.
There are two Executive Committees (ECs): one for the J2ME platform and one for the J2SE and J2EE platforms. I will be serving on the J2SE/J2EE EC, which means I'll be working with other EC members to determine which JSRs are approved for development and become final specifications. That's a huge responsibility. There are only 16 members on the EC and you need a majority with at least five "yes" votes in order for a JSR to pass each milestone in the JCP process. That means as an individual, I'll have a lot of responsibility and potentially a large impact on how the Java platform evolves for the next couple of years. I don't take that lightly.
JDJ: What does this mean for you? What are your duties?
RMH: I'll be flying to California and elsewhere about four times a year for in-person EC meetings, and also meeting in conference calls about once a month. It's a lot to take on, but the opportunity to help shape the future of Java is just too important to pass up.
I'm an independent, which means I won't be representing a big business interest. I'm going to do my best to represent Java developers who are not a part of the process. I also want to see that the needs of the open source community are represented - Apache already has a member on the EC, Geir Magnusson Jr., so I feel I have an ally in that endeavor. I'll also be looking to Doug Lea for guidance on how to work effectively as an independent in an organization dominated by big business interests.
JDJ: Sounds like a tremendous amount of responsibility.
Is there a direction you are looking to steer Java? What areas will you be specifically looking at when new proposals come through?
RMH: I'll be looking for a couple of things, including JSR overlap, industry relevance, and ease of use. The first two criteria are part of the charter of the EC members. The EC wants to avoid overlap among JSRs and also to ensure that the JSRs are useful and needed by their target industries. The ease of use thing is a personal crusade. Java is an awesome platform and J2EE is quite impressive, but the number of APIs is massive and their complexity can be daunting. I'll be looking for JSRs that improve usability from a developer's perspective.
JDJ: The JCP gets a fair amount of stick from various quarters of the Java community. On the whole do you think it's working?
RMH: The JCP has, in my opinion, improved a lot with the latest version of the process. There is always room for improvement, but overall I think the JCP has done well. I wouldn't have taken my seat on the EC if I felt otherwise.
JDJ: You have been writing about Java for many years now. Over that period, how do you feel we've matured as a community?
RMH: In the early years everything revolved around the Java programming language. How to use the core APIs and what VM technologies are best. Those things are still important, but eventually developers turned their attention to APIs outside of the core, like JDBC and EJB - and now J2EE and J2ME. Lately developer interest has turned to architecture and design - a good sign that Java has matured. Rather than focusing on how to use Java APIs, the community is turning its sights on when and where to use Java in larger enterprise systems.
Another thing that changed is the question of Java itself. When I first got started in Java (end of 1995) I spent half my time programming in the language and the other half evangelizing it. Today it's very different. Java is the first programming language taught by many learning institutions and just about every large corporation is using it somewhere - often in mission-critical applications. The question has changed from "Why should we use Java?" to "Which Java technologies should we use?"
JDJ: Tell us a little about your latest book, J2EE Web Services. Are Web services finally being adopted in the field?
RMH: This is probably the best book project I've worked on. It took me twice as long to write as I originally thought it would because it turns out that J2EE Web services is a huge topic, and its takes effort to explain it clearly. I (and a lot of other people) think Web services are important because they're really useful when connecting disparate systems. This isn't necessarily because Web services is based on XML and HTTP; it's because Web services is endorsed and supported by every major software vendor, including Sun, Microsoft, IBM, BEA, HP, and Oracle. The cover of my new book has an 18th-century Japanese woodblock print of a giant wave, which was inspired by the tidal wave of industry support behind Web services. It reminds me of the kind of support we saw behind Java and XML when they were first introduced.
The book I wrote is really a developer's guide to the Web services technologies (XML, SOAP, WSDL, and UDDI) and the J2EE Web services APIs (JAX-RPC, SAAJ, JAXR, and JAXP). Although I originally planned to cover architecture and design, I had to stick to explaining the technologies because they are so vast and deep. In the end, I'm enormously satisfied with the book - I believe it will be very useful to developers implementing J2EE Web services.
JDJ: Are you working on anything at the moment?
Are we going to see another book from you in 2004?
RMH: O'Reilly will be publishing Enterprise JavaBeans, 4th Edition in 2004. I'm working on that right now and I'm almost finished.
As an author, my major focus for 2004 and 2005 will be on a new book about the Java platform, tentatively titled This Is Java. There's a lot of books that focus on the anatomy of Java, its programming syntax and core APIs. This book doesn't cover that stuff. Instead, This Is Java will address the physiology of the Java platform by explaining how Java manages threads, I/O, networking, classloading, and things like that. Although it sounds like a JVM book, its scope is broader. The book not only explains how Java works under the hood, but why it was designed the way it is, and how to leverage that design to produce more efficient and performant code. The objective of this book is to make every reader an expert on the Java platform.
I think today most Java developers are like race car drivers who know how to drive, but don't understand how their car is put together. In the sport of auto racing the best drivers know their cars inside and out and can build, tune, and fix them as well as drive them. Similarly, the best Java developers know how Java works inside and out. This Is Java will make that knowledge accessible to all Java developers.
JDJ: Take a moment and have a think about Java's history. Name one thing that Java has done right and, conversely, is there anything in Java's history you would like to change?
RMH: Java was built from the ground up to be an object-oriented, network-savvy programming language. I think we got that right. James Gosling and crew created an elegant and powerful programming language. The thing I look back on with less excitement is Swing. I think Swing set the Java platform off its desktop course and gave ground to other technologies. I'm also a bit remorseful about the complexity of the J2EE APIs - while they are pretty cool, they are on the whole, I think, too complex and probably a bit daunting for many developers.
JDJ: Have we lost the desktop battle to the likes of Flash and .NET?
RMH: We have lost a couple battles but not the war (sorry for the cliché). In my opinion, AWT delegated too much to the OS while Swing delegated too little - Swing is also too complex. A compromise, perhaps something along the lines of SWT, is needed to make Java as popular on the desktop as it is on the server. I'm confident that we will get there; it's just a matter of time.
JDJ: Let's imagine for a moment I wanted to invest serious money in a Java startup company. What type of company would you advise me to put my hard-earned dollars into? What's going to be big in the next 18 months?
RMH: On the server side, I think tools that enable developers to quickly and easily expose existing and new systems as Web services will be big in 2004. On the desktop, I would keep an eye on the Java IDE market. I think we'll see a lot of consolidation in that area.
In the long haul, I think open source is going to pressure vendors in many markets to focus on usability rather than utility. Open source has a tendency to commoditize markets, but it also offers vendors a lot of opportunity when it comes to making utilitarian software easier to manage and use.
Of course, these are only my opinions, and if I was right more than half the time I would probably be retired already. I'm not an investment advisor, so take these opinions with the appropriate amount of salt - a metric ton or two should do.
JDJ: Many have complained J2EE is too unwieldy and
complicated. Do they have a point? Or is the latest generation of development tools easing the pain?
RMH: Yes, they do. For the past few years the J2EE community has focused on supporting enterprise computing in a way that is portable and, more recently, interoperable across a host of products. That's pretty difficult to do without introducing some complexity because enterprise systems are inherently complex. However, now that we have addressed the complexity to a large degree, I believe it's time to turn our attention back to ease of use. Specifically, I'm interested in offering application developers a simpler programming model for the entire J2EE platform. I don't want to throw out the APIs we have today, because they offer a level of granularity and portability that's crucial to the J2EE platform, but we should offer a broader abstraction of the J2EE platform that will rest on top of the standard APIs, a programming model that is more implicit and intuitive and less complex and explicit. That is going to be a big focus for me over the next couple of years - making J2EE easier to use without sacrificing the portability or sophistication of the platform.