The most compelling argument for using the Java language for software development projects is that it offers increased productivity. Fewer programmers can accomplish more, and do it better, in less time using Java. The IDC report "Java Pays -- Positively" on May 1998 [1] documents and analyses the experiences of 9 companies transitioning from C++ to Java. Jennifer Jessup's column in the March 1999 issue of Software Development magazine summarizes the IDC results:
In 1990, when Java was still just an idea, Gosling knew that this new language had to focus on developer productivity. He concentrated on reliability, object-oriented capability, and initiating early error checking. As enterprises migrate from C++ to Java development systems, formal studies -- such as IDC's "Java Technology Pays Positively" -- are showing that developer productivity is increased two-fold. According to IDC's study, the productivity has increased because Java's discipline yields a tighter object-oriented framework and fewer errors during unit testing. The plethora of available Java development tools also helps developers leverage the language's power quickly and efficiently. [2]
A more detailed summary of the report written by Jon Byous appears on the Sun web site:
IDC's study, "Java Technology Pays Positively," published in May 1998, is emphatic on the cost savings gained by early Java technology adopters. "International Data Corporation found that projects built with the Java language, targeting the 100% Pure JavaTM standard, yielded an average of 25% savings when compared to C++ for development projects requiring multiple platform deployment. Coding phase savings were even more dramatic, averaging nearly 40%."
The study predicts that the participants will experience additional savings of 10-20% per year in production support and 30% or more on ongoing code maintenance...
Two factors were credited by IDC as key in delivering these high development cost savings: built-in memory management and simplified object orientation. "The Java language naturally instills a discipline that yields a tighter OO framework and fewer errors during unit testing," states IDC. ..
The maintenance phase shares many characteristics with the coding phase, and the study probed expectations about ongoing maintenance, stating, "Most companies also felt that Java software would be far easier to maintain, producing maintenance savings nearing 30% on average." ...
So according to IDC, gains in development efficiencies are great using Java technology. But often the real value of project development to an organization is in the market advantage the applications deliver.
IDC followed up on what happened to the adopters' Java technology projects after completion, for example: "On the corporate side, the United States Postal Service experienced a renaissance of market benefit directly related to its Java technology adoption. The Postal Service's Java software development efforts have led to new customers, improved customer satisfaction, and in some cases, improved internal morale."...
... McKenna says: "I have a couple of junior programmers here, and the Java language easier for them to work with. And even with my experience, there are just so many more mistakes you can make with C++ that it isn't worth it." ...
IDC's independent study is great news for any organization currently developing projects using Java technology. IDC draws clear conclusions about its findings: Java technology-based development pays in big savings, especially in the coding, unit test, production support, and code maintenance areas of the development lifecycle. [3]
The June 1998 issue of Communications of the ACM was focused on "The Java Factor". In Paul Tyma's lead-in article on "Why are we using Java again?", he briefly mentions the promise of platform independence, then concentrates on productivity:
The more overlooked side of platform independence is Java's rather fantastic abstraction of many programming paradigms.
Java's automatic memory management, operating system abstractions (through its APIs), and familiar low level syntax (at least for C programmers) make it a curiously productive environment. Most new Java programmers are surprised at how they are able to get something (anything) to work almost immediately. Before you're required to learn all there is about object-oriented programming, multithreading, remote method invokation, and the like, you can take a prebuilt piece of code, intuitively modify it, and get something up and running quite rapidly.
New C programmers inevitably write to some wayward pointer or commit some other fiendish memory-violating act that causes anything from "General Protection Faults" to system lockups. The guarded memory model in Java makes crashing the system much more difficult (although not impossible). Needless to say, crashing the system is a highly unproductive act.
The entire interaction with memory is worry-free in Java. When you want some memory you take it, when you're done with it, you walk away from it. This abstraction relieves the programmer of system "details." An alternative view (and one popular with C programmers during their transition to Java) is that Java is extremely limiting in terms of memory control. Compared to C, this is certainly true. However often, the word flexibility is synonymous with responsibility. Humans inevitably make mistakes and often fail to be responsible with memory management (dangling pointers, memory leaks, and so forth). Java relies on the fact that algorithms don't make mistakes and controls memory for you (at the cost of some run-time performance). It's been my experience that most hardcore C programmers eventually embrace this productive paradigm in spite of their lost flexibility.
Java programmers need only learn one set of APIs for all operations. Writing network code is the same regardless of which platform they are using. In C and C++ environments there are a plethora of choices for networking APIs -- in fact, this is the problem. Two C programmers writing networking programs might not even be able to describe their respective projects to each other. Java programmers are always on the same level, regardless of their underlying environments. The number of APIs is vast, but if you learn them once, that's all you need to know (until the next release, of course)... [4]
A recent paper on the Sun web site reinforces these views on Java productivity with case studies from a number of companies that have experienced big productivity improvements by using Java [5]. An early paper by James Gosling [6] shows that increased development productivity and flexibility were primary design goals that guided the language design. Significantly increased productivity is no accident - it was designed for better productivity based on a lot of prior art.
[1] "Java Pays -- Positively", by Evan Quinn & Chris Christiansen, IDC Bulletin #W16212, May 1998. See http://www.idcresearch.com/ and search for "java pays" for ordering information.
[2] "Java from the Horse's Mouth : An inside look at how Java has increased developer productivity", by Jennifer Jessup, Software Development, March 1999, page 73. See http://www.sdmagazine.com/breakrm/grazing/s993tc.shtml for ToC citation.
[3] "A Jolt of Efficiency", by Jon Byous, http://java.sun.com/features/1998/07/efficiency.html, full text available, revised April 1999.
[4] "Why Are We Using Java Again?" by Paul Tyma, Communications of the ACM, June 1998 (41,6), pp. 38-42. See http://www.acm.org/dl/ and search for "java again".
[5] "Java Technology Comes of Age", by Rich Levin, http://java.sun.com/features/1999/05/birthday.html, full text, May 1999.
[6] "The Java Language : An Overview", James Gosling, http://java.sun.com/docs/overviews/java/java-overview-1.html, full text, 1996.