I recently attended the SIGS 1996 C++ World conference for the 4th year in a row. Each conference has had a different set of ``hot topics.'' The hot topics at the 1993 conference in Dallas were exception handling and templates; at the 1994 conference in Austin the hot topic was STL; at the 1995 conference in Chicago the hot topic was componentware (e.g., CORBA and COM). Not surprisingly, the hot topics this year in Dallas were Java and the WWW. SIGS devoted 1/6th of the conference to sessions on Java programming and many vendors on the exhibit floor were promoting their Java tools, books, and training services.
In addition to the sessions on Java at C++ World, I participated in a panel entitled ``Java: Friend or Foe,'' which attempted to pit the languages and language communities against each other. Although these debates make for great theater, I believe that framing the discussion as ``C++ vs. Java'' misses the point for the following reasons:
I've been a ``language pragmatist'' ever since I first began programming. To me, languages are tools, not sacred deities. I consider a programming language ``good'' to the extent it facilitates the design and implementation of useful software. I've written useful software in many languages, starting with Pascal in the early '80s and continuing with Ada, C, C++, Eiffel, and recently Java.
As with any tool, the key to success is knowing how and when to apply it properly. C++ has been my language of choice when modularity, extensibility, run-time performance, and access to platform-specific features are crucial requirements. However, I plan to use Java for those situations where cross-platform portability, dynamism, and simplicity of memory management take precedence over run-time performance. As my Australian colleagues are fond of saying ``it's horses for courses.''
C++ and Java support roughly the same set of OO language features. Therefore, it's not surprising that many of the OO programming skills and patterns we've learned using C++ translate nicely into Java and vice versa. Historically, the traps and pitfalls of C++ have centered on the effort required for memory management and cross-platform portability. Unfortunately, these tactical concerns often distract us from more strategic software architecture and design issues.
Many universities have begun teaching Java in their introductory curriculum. Therefore, I'm optimistic that the next generation of programmers using C++ will be much better prepared to master of the patterns, protocols, and principles that can resolve strategic design challenges.
To meet this demand, several articles this month explore the relationship between C++ and Java. Robert Martin critiques the key features of the two languages, Prashant Jain and I present our experiences converting a large communication software framework from C++ to Java, and Graham Glass describes how the C++ STL library has been ported to Java. I expect you'll be seeing more discussions and comparisons of C++ and Java during the coming year. As always, the C++ Report will bring you objective, leading-edge coverage of the strengths and weaknesses of these important languages and development environments. In particular, look for columns by John Vlissides and others that explore relationships between design patterns that are common in C++ and Java.
Back to C++ Report Editorials home page.