Is Java Ready for Prime Time Industrial Use?

By Steven Pike
Microelectronics, IBM

Abstract

The question of Java's readiness for prime time industrial use has been posed by management and technical staff across the industry. The answer to the question needs serious consideration of the facts at hand and a little intuition about the future. Consideration of the facts is a tedious struggle, because so much hype surrounds Java that perceived facts are in many cases only strong opinions.

This paper will attempt to cut through the hype to arrive at demonstrable facts, about Java's readiness for serious industrial application development.

We will look at the current industry players and their strategies. Although admittedly a technical person, I will attempt to quantify the business risks and provide the basis for justification.

No assumptions are made; Java is fully explained and compared to known entities. I would like to believe at the outset that this paper is sufficiently definitive to allow for solid management and technical commitments.

Feedback is welcome: I can be reached via e-mail at srpike@us.ibm.com.


Table of Contents




The Technical Side...

What is Java? What isn't it?

Java is a programming language, not a Web tool. The industry in general would have us believe that Java starts and stops with the World Wide Web; it does not. Industry pundits compare Java to Microsoft's Active-X and spew the pros and cons-these two are not comparable.

Java is comparable to C, C++, and other computer languages. It is on that basis solely that technical strengths and weaknesses can be determined. All other comparisons are hype, marketing, or other errata!

The official definition from Sun Microsystems, who develops and licenses Java, is as follows:

Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic language.
[
The Java Language, An Overview@ http://www.javasoft.com/docs/Overviews/java/java-overview-1.html]


What is the history and the merit of the Java language?

When selecting a language for developing any new application, the programming staff needs to examine the language choice to optimize development time, reuse any existing code, exploit language traits, etc. This has been a time-honored tradition. Let's step back about 25 years or so. Popular languages of that era included Fortran, which was good for scientific applications; APL, excellent at array manipulation and math intensive applications; COBOL, a business language; and the list goes on. There were die-hard assembly language and machine-level programmers, absolutely possessed by speed and performance.

The choice of the language at that time was not market-driven; it was based upon the application. The language that offered the best utility and function library was usually the choice. Programmers chose the language; the customer had little interest in how an application was written.

In 1978, a couple of fellows by the names of Dennis Ritchie and Brian Kernighan at Bell labs published the "general-purpose" language on the UNIX operating system. A revolution in computer languages was at hand. The time it took for acceptance of this language was almost 5 years. At this point, in 1983, the ANSI standards committee adopted a standard for the "C" language. Next, "C++", embracing object-oriented principles, took the dominant "general-purpose" title. Still, language choice was pretty much at the discretion of the programmer. Management, however, seeing the benefit of common programming languages for maintenance and easier deployment, began to order in many cases that C or C++ be used. The end-user, too, became aware that, if C or C++ were being used, maintenance could be done easily, because a great number of programmers were available that understood that base.

As C and C++ matured, the weaknesses of the languages, or the areas that caused the most maintenance, also became quite evident. Programmers were analyzing memory leaks and chasing null pointers, locked in a battle of wits with the operating system about event management and thread dispatching. The end results were worth the effort, however, as compilers and linkers were optimized to execute the code in near-machine speed.

Programming shops in general developed expertise from the ground up, and in most shops there are but one or two highly-qualified experts that can find those nasty esoteric inter-thread system-hanging problems that the other programmers unknowingly put there. Most programming errors are introduced because programs are so complex that they are written by teams, not by one individual who controls all the variables. If ground rules for team members are loose, all types of "bugs" can be introduced to the code at integration time that were not there during testing of individual code segments. These "bugs" can be quite insidious, and can easily put projects significantly behind schedule. C++ and object-oriented techniques helped greatly in reducing the "bug" rate. As data and code were encapsulated, an object became an island unto itself, and once again one programmer could contain all the details of one object, and the rules for connecting objects became clear. Still, not one C++ compiler is happy about being able to use other C++ -compiled objects, but if regimented to a single development environment, things are very stable.

But, what if? What if a language removed all of the areas that caused the bugs? What if memory management, pointers, and thread concurrency problems were no longer anything a programmer had to concern himself with? What if the rules of object interaction were so well-defined that they allowed operation on any operating system without change? What if your programmers only had to write one source for every operating system? What if the object-oriented paradigm that helped so much were embraced tightly? What if error-detection management was enforced so that programmers had no choice but to code in error-handling and recovery? Well...to that end, you would get JAVA! That is what the language does--and it does it very, very well!

For an in-depth view of Java's most prominent features, review Datamations article written by Arthur van Hoff, Sami Shaio, & Orca Starbuck, or the that accompanies this white paper.
[
What Is This Thing Called Java? @ http://www.datamation.com/PlugIn/java/03ajava7.html]

James Gosling, a Sun fellow and Vice President, did just this. He is an expert C and C++ programmer who was challenged with making a small language for micro devices for firmware. It was to be a "general-purpose" language. It wasn't readily accepted for its purpose(it was called OAK in those days), but Gosling realized that the Web would benefit from it. The name OAK was not accepted because other companies were using it, so after many visits to the local coffee shop, the team came up with the name JAVA! Jim's perspective on the future of Java, Microsoft, networks, and C++ is very informative Read about it in Datamation magazine's interview with Jim.
[ Gosling on Java @ http://www.datamation.com/PlugIn/java/03ajava2.html]
[xref: Java Complete @ http://www.datamation.com/PlugIn/java/index.html]

The bottom line? Java is a better programming language then C++. Regardless of the project or the target application, Java will provide better code, code that is faster and easier to maintain. If Java had simply been called C2++ or C+++ and the compilers for native support had come first, no questions would have been asked. It would have been adopted as the new de facto C++ replacement, even in its first release. The fact is, though, that it is more-- much more--and the aforementioned benefits are all gravy!

What are the Java language specifics?

OK, hype aside, let's look at Java in more technical detail. First the merits of the language, then the extensions, support, and tooling. Wherever possible, links are provided to expound the details presented here.

  • No Pointers... No memory management--garbage collection is automatic
  • Cross Platform--full libraries, AWT, NET, IO, UTIL, LANG
  • Interpreted--but not like BASIC
  • Fully OOP
  • Compiler forces error code and handling
  • C++ Syntax--Very easy learning curve (from C++ background)
  • FAST--Libraries are very inclusive! more coming...
  • Compiled byte-code, secure, portable, Webable!
  • JVM--28 and counting... all major operating systems
  • Can wrapper C, C++, legacy code, drivers, etc., or be wrapped
  • A better C++


What are JavaBeans?

JavaBeans is Java's answer to Active-X, Open-Doc, OLE/COM, SOM/DSOM, etc. For serious development, beans are the way to go; reuse starts at this level. The best definition comes in a memo from Javasoft@http://splash.javasoft.com/beans/, which I quote below:

Memo to Java developers
The choice is clear: Write to JavaBeans

Throughout the industry, JavaBeans is the component architecture of choice.

More than 400,000 developers around the world have already embraced the Java platform. And no wonder. Java has opened up an entirely new world of opportunities for building fully portable network-aware applications. Yet many developers are not yet sure how best to take advantage of the capabilities and benefits the Java Platform delivers without sacrificing their existing investment in legacy applications.

The answer is JavaBeans.

JavaBeans is the platform-neutral, component architecture for Java. It's the ideal choice for developing or assembling network-aware solutions for heterogeneous hardware and operating system environments--within the enterprise or across the Internet. In fact, it's the only component architecture you should consider if you're developing in a Java environment.

JavaBeans extends Java's "Write Once, Run Anywhere"SM capability to reusable component development. In fact, JavaBeans takes interoperability a major step forward--your code runs on every OS and also within any application environment. A Beans developer secures a future in the emerging network software market without losing customers that use proprietary platforms, because JavaBeans interoperate with ActiveX. JavaBeans connects via bridges

The JavaBeans specification--which was completed ahead of schedule--defines a set of standard component software APIs for the Java platform. The specification was developed by JavaSoft with a number of leading industry partners and was then refined based on broad general input from ISVs, customers, and end-users during a public review period.

into existing industry component models such as ActiveX. Software components that use JavaBeans APIs are thus be portable to containers including Internet Explorer, Visual Basic, Microsoft Word, Lotus Notes, etc.

JavaBeans allows developers to create reusable software components that can then be assembled together using visual application builder tools, such as Borland's JBuilderTM, IBM's Visual AgeTM for Java, SunSoft's Java WorkshopTM and Symantec's Visual Cafe, and many, many others.

 

The creation of Java Beans is very easy with IBM Visual Age for Java. IBM also has a bean development project well under way that we can use. Javabeans is simply a set of rules and packaging techniques to apply to written classes. It makes reuse extremely easy. All serious development should be at the JavaBeans level if reuse and maintainability is the goal.

The Business Side...

OK, the technical reasons are sound. Now let's look at the business side of the equation. I hope the following hypothetical Q & A format covers your questions.

Questions and Anwers

QUESTION
"Computers in the future may weigh no more than 1.5 tons."
--Popular Mechanics, forecasting the relentless march of science, 1949.

"I think there is a world market for maybe five computers."
--Thomas Watson, chairman of IBM, 1943.

"I have traveled the length and breadth of this country and talked with the best people, and I can assure you that data processing is a fad that won't last out the year."
--The editor in charge of business books for Prentice Hall, 1957.

"But what ... is it good for?"
--Engineer at the Advanced Computing Systems Division of IBM, 1968, commenting on the microchip.

"There is no reason anyone would want a computer in their home."
--Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977.

In general, the 1.1 release of Java direct from Sun is very stable. It was a departure from 1.0 in many ways, but the explanation offered was, "Lets do it right now--let's get on the right track and not have to provide patchwork for all future levels." I believe this was a good technical decision, and making this decision early certainly affected the fewest number of users. The expectation of all is that 1.2 and future releases will include new functions and enhancements, but not radical changes. I believe the 1.1 level to be stable, and I believe that is is the platform to use for application building.

Java is very well defined at this point and is now being pushed as an industry standard by ISO itself. The official Java study group ISO/IEC JTC1/SC22 JSG can be monitored at http://www.dkuug.dk/JTC1/SC22/JSG/.

QUESTION
Cross-Platform is a nice promise, but there are different Java levels on many systems, all changing at different rates, and to a certain degree not all JVMs are created equal. Why would I want this? ANSWER
The simple answer is: You don't. It would be ideal if the Java suite moved on all platforms at the same time and all JVMs absolutely worked the same. But what other choice do you have? If your shop currently does multi-platform support, then you have experts for each operating system and you generally develop on one, but release and then port to the others--all these steps are staggered. Java will remove 90% of the burden, and third-party testing centers can validate your code on other platforms and provide the necessary small patches if required. If your shop currently only develops for one platform, then Java will do it very well, and you can optimize as needed. If the other platforms work by default, then- great! You just got new markets for free!

The bottom line: Develop, using Java, on the platform you always use; don't be concerned about the cross-platform issues. Those can--and will--be worked out at the end. It is not a development issue, but a deployment one.

QUESTION
What's the learning curve? I just got everyone up to speed in C++. ANSWER
In general, C++ programmers pick up Java very fast. Since Java is simply a better C++, in most cases its only a change of rules. However, learning the class libraries and learning which classes to use at which times will require experience.

The average programmer becomes proficient in the language in about 2 months; the range is probably 1 to 3 months. The good news is that it can be learned while working on a prototype because iteration for changing classes or code more efficiently is very fast. Several courses offer a head start, and there is a myriad of books available. As with most languages, programmers really learn it when they have to use it. For a non-C++ programmer or, perhaps more important, a non-OOP programmer, the learning curve is about the same as for C++ and OOP.

QUESTION
I have a business to run. Writing in C++ is efficient and serves my purpose, and I understand the process very well. At this point, I know C++ will produce faster code as well--why would I want to change? ANSWER
As was the promise with C++, reusability, OOP, and maintainability were the key issues that sold the language. The same arguments hold true for Java. Java is a better C++, and many have called it C+++. In addition, there are new marketing opportunities.

Currently C++ will produce native code. The Java 1.2 edition promises near-native speed, and compilers for native binaries are available now on popular platforms. And more is coming. The performance argument will become a non-issue shortly.

QUESTION
Will I be able to use Java for device-specific code (i.e., device drivers and the like)? ANSWER
No,but you probably don't deploy device driver code today in OOP languages, either. Most are done in assembly or "C" to get as much system performance as possible. That business will not change-- unless of course using JavaChips and JavaOs on device drivers become the industry standard- then device drivers will be done in Java!

Real business using Java

Sometimes, even after all the research, doubt lingers and the "show me, I'm from Missouri" attitude prevails. With that in mind, I have cataloged several serious applications, as well as businesses that have adopted Java early in their experience. At the time of this writing, all of these links are valid.

"SAVI application suite, developed by OMIX. This Castanet-powered, mission-critical application suite allows real-estate professionals to list, search, and view property listings, as well as order newspaper advertising and area mailings. SAVI was created by OMIX for Alain Pinel Realtors and was deployed in March. The objective of the application suite is to boost productivity for Alain Pinel's sales executives by automating time-intensive and laborious tasks by using Java. SAVI also generates Comparative Property Analyses, which help make the best pricing decisions when listing or buying a property.

This application is intended for Alain Pinel's internal use on a 10BaseT Ethernet LAN. However, the system will also be accessible by customers using a dial-up connection. SAVI creates a virtual office for over 400 sales professionals which is accessible anywhere, anytime to instantly search for information, maps, and images of regional properties. Since SAVI is a mission-critical application for Alain Pinel, reliability is very important."

[re: quoted from Arthur van Hoff (founder and CTO of Marimba)]



CERA Online, one of the world's leading banks, gets worldwide attention using Java.

Central to the bank's efforts to enhance retail services is the groundbreaking work it is doing serving Java applets from an OS/2-based Web server. The accessibility of CERA Online allows the bank to nimbly react to competitive moves by quickly making new services available to its customers.

The beauty of the system lies in the centralized control from the IBM high-end enterprise server located at headquarters, combined with the capability for wide distribution through CERA Online. The move to this network computing model eliminates the support costs associated with decentralized systems.

CERA's first retail service application, built to the 100% Pure Java standard, is a loan mortgage calculator that allows potential borrowers to estimate payments from their home computers using only a browser. Through this service, the bank reduces loan application processing time.

[re: Java Case Study, IBM Network Computing @ http://www.ibm.com/java/bus_case_cera.html]



infoBook by ChipSoft, Inc. is a full Java application [re: How to develop commercial-quality Java programs @ http://www.javaworld.com/javaworld/jw-01-1997/jw-01- infobook.html]



"Corel Office for Java delivers a complete client/server enterprise solution that not only includes popular productivity applications but also provides work-group functionality and back-end enterprise support. Corel is committed to developing a product that is fully based on open Internet standards. Corel Office for Java meets the needs for full featured, portable productivity applications in the new thin client computing environment. In addition to the client software, Corel Office for Java features a Java implementation of LDAP (Light-weight directory access protocol) for server side administration of users, applications, and documents."

[re: quoted from Corel Press Release]



Glossary

Applet Java code missing the application framework, which is provided by an Internet browser. Applets operate in highly secure mode, and in general have restricted I/O privileges.
Introspection The ability of a JavaBean to self-describe itself and its use.
Java A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic language.
JavaBean A software component model for Java.
JavaOs Sun's imbedible operating system, designed to run on chips, smart cards, etc.
RMI Remote Method Invocation -- A defined way for a Java application to remotely invoke Java objects.


Bibliography

Bowen, Barry D. "Software Reuse with Java: Finding the Holy Grail." May, 1997 feature on http://www.javasoft.com/

Duntenmann, Jeff. "The Crazy Years Are Here Again." Foreword, JAVA Programming Language Handbook, 1996, Friedel and Potts, Coriolis Group Books

Eckhoff, Randy. "BeanMachine: Adding Life to your Web Site." IBM Developer Connection News, June 1997, Release 2, p. 15.

Gupta, Suchitra; Hartkopt, Jeff; and Ramaswamy, Suresh. "Java through the Eyes of a C++ Programmer (Part 2)" Java Developer's Journal, March 1997, Vol. 2, Issue 2, p. 20.

"Introducing a Java Class for Persistence and Scalability." Java Report, May 1997, Vol. 2, Number 5, Sigs Publications.

"Java as Client and Server." Java Report, May 1997, Vol. 2, Number 5, Sigs Publications.

"Java compared to C/C++." http://rad.hcf.jhu.edu/~ian/javafyi/javacompare.html

Kaminsky, David. "The Case for 100% pure Java." http://www.ibm.com/java/community/viewarchive3.html

MacDonald, Patrick, and Yang, Shili. "JDBC: Open Database Access and Platform Independence...But How do I use it?" IBM Developer Connection News, June 1997, Release 2, p. 9.

Nunn, Hal. "100% Pure Java--Questions and Answers with Hal Nunn." May, 1997 feature on http://www.javasoft.com/

Renshaw, David S. "JavaBeans: The Perfect Roast?" IBM Developer Connection News, June 1997, Release 2, p. 3.

Scheier, Robert L. "Managers aren't jumping for Javajoy just yet--Jury's still out." Special Report: JAVA Reality check on Java hype, Computerworld, May 12, 1997, Volume 31, No 19, p. 73.

Spivak, Nova. "Should Java Be an open standard?" Java Developer's Journal, March 1997, Vol. 2, Issue 2, p. 7.

"Sun's New JavaSpaces Redefines Distributed Computing." Java Report, May 1997, Vol. 2, Number 5, Sigs Publications.

"The San Fransico Project." http://www.ibm.com/java/sanfrancisco/

"Using the Factory Design Plan." Java Report, May 1997, Vol. 2, Number 5, Sigs Publications.



JavaTM is a trademark of Sun Microsystems, Inc.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright   Trademark



  Java Feature Page Java Home  
IBM HomeOrderEmploymentContact IBMLegal