eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If youre headed to San Francisco, as I am, for this weeks JavaOne conference, you probably share my sense that this baby has grown beyond all reasonable expectations since it was born in 1996. The Java tutorial book I wrote that year, following the debut JavaOne event, covered most of what you could do with the language in fewer than 400 pages and about 100,000 words. If I wrote a second edition today, it would have to be three times that length.
Fortunately, developers growing tutorial needs have been well-met by other writers, although Im sure theyve been challenged to keep pace with Javas rapid development. Bruce Eckels “Thinking in Java” is in its third edition, David Flanagans “Java in a Nutshell” in its fourth, and the two-volume “Core Java” set by Gary Cornell and Cay Horstmann in its sixth. Written from different perspectives for readers with different needs, each has its particular fans, but as a group, these books stand above the crowd.
Even so, I expect to see a surge of investment in new Java teaching materials and skills between now and this fall, when high-school advanced placement computer science classes will start using Java after a brief flirtation with C++. (More information is at ,a href=”http://www.collegeboard.com/ap/students/compsci”>www.collegeboard.com/ap/students/compsci.) I didnt think much of the AP programs C++ experiment, which began at just about the time that Java had clearly become a more attractive language for such purposes. Its way too easy to write C programs, compile them with a C++ compiler and think that youre learning modern programming practices.
When people tell me they prefer the greater freedom they get by writing in C/C++ or even in Microsofts C#, I think of Java creator James Gosling at Sun telling me that Java was designed to prevent the most common kinds of programming mistakes. Id rather see clever users freed from the need to work around tiresome bugs than see clever programmers shaving a few more microseconds from task times.
High on the agenda at JavaOne this week will be forthcoming language changes that will give tutorial authors their marching orders for future editions. Plans for Java 1.5, for example, include a mechanism known as generics; this feature in a programming language allows a programmer to write at a conceptual level about things that might be done with any type of data, only later specifying the actual type of data to be used. We need this leverage in dealing with ever-richer media.
The trade-off, as usual, is between making programmers more productive when they write code and making enterprise systems more efficient when they run it. The challenge is to minimize performance penalties, as Java moves into ever-more-performance-conscious environments, including high-throughput server applications and resource-limited portable devices.
Its important not to demand, though—even when its possible—that a favored tool be extended to suit every function. The result may be as versatile, but also as clumsy, as one of the larger versions of the Swiss Army knife. Twenty-first century or not, there are times when machine code is the right thing to be writing.
Even Suns own Java technology evangelist, Raghavan Srinivas, warned in a java.sun.com interview that “one misconception is that Java technology can be used anywhere. … I dont think Java technology is a silver bullet.”
But dont sell Java short; advances in run-time compilation techniques (not to mention increasingly faster hardware speeds) are making it a more plausible choice for many speed-sensitive tasks than many IT builders may think. Improved analysis tools, such as Borlands Optimizeit, warn programmers when they misuse Javas strengths—for example, when they write code thats extravagant in constructing temporary objects, consuming resources for both their creation and destruction.
What it all means is that developers who may think they know Java should recognize that continued mastery requires continued learning. Enterprise IT architects who think theyve taken the measure of Javas possible contributions to their plans should be constantly re-evaluating their assessments.
I look forward to greeting many of you at JavaOne and to being pleasantly surprised and challenged there this year and for many years to come.