Java - Ready for Prime Time?

Is Java really the next silver bullet for embedded programming?

Published in Embedded Systems Programming, August 1996

By Jack Ganssle

New, Free, and Sex are the three golden words of marketing. Any of these are guaranteed to get a reader's attention, and all are employed in different mixes on far too many commercials and ads. Of these, I think we techies fall prey to the siren of new far too often. In an industry where all the rules change biannually, new is the hat we peg our futures on.

In the software industry nothing is newer - or seemingly cooler - than Java. The pundits will have you believe that all new applications are coded in this dialect, and that all developers are lemmings engaged in a mad dash towards some sort of Java success - or failure.

I'm wary of Java, as I am of every new computer language. Though, like all of us, I revel in new technologies, and love to play with the latest cool thing, I do try to temper my enthusiasm with an occasional hard dose of common sense.

Your code is likely the most valuable asset your company owns, even though (incredibly!) it appears on no balance sheet or accounting statement. Any decision that profoundly affects this asset has serious implications for the success of the business - and for your continued paychecks. A critical part of engineering is risk management - getting a reliable product out, more or less on time, more or less within budget, despite the inevitable problems we know always occur. Smart developers minimize the risk of new technologies, deploying them only when it makes sense.

We're a conservative bunch. Maybe not politically or socially. Certainly we are in our products, where problems can be literally life threatening

In an attempt to understand the substance behind the hype, recently I have been writing a bit of Java code but for Internet applications. It's too hard to learn a new language on embedded systems, where the interactivity and spontaneity of coding on a PC are missing.

Java is indeed cool, particularly its ability to toss applets to a user's browser. I find small applets easy and intuitive to code. The potential blows my mind.

It also blows my browser. Netscape's latest non-beta release (life is too short to spend it beta testing Netscape's release de jour) frequently crashes when confronted with Javascript.Corresponding with Internet service providers confirmed that these crashes are all too common.

Disabling Javascript on my Netscape browser effectively disables this applets - except for the one on Netscape's home page. Bug? Insidious intrusion into my machine?

OK - Java is new. Java interpreters are buggy. Real Soon Now these problems will go away.

Therein lies one of my concerns. On the net a buggy applet is no more than annoying. Disable the browsers's Java option and carry on. Embedded systems are far less tolerant of these sorts of problems. When ten thousand computerized Coke machines decide to swallow quarters all day without releasing the hoard of sodas, expect to find the crew of 60 Minutes camped on your doorstep.

Smaller Languages

I wonder if we're seeing a backlash against large, complex languages. ADA, the very model of a modern major lingo, never really caught on. ESP's own surveys show that only about 10% of the market uses it.

Yet, in a sense, ADA takes the most reasonable tact of any language. Nothing is ADA unless it's 100% compliant with the spec, as measured by an exhaustive test suite.

C++ seems to be drawing some attacks. I've been fascinated to read P. J. Plauger's columns about subsetting it. I'm hearing that many developers find C++ too big and complicated. Subsetting is a bad thing, unless rigorously controlled by standardization. I still remember the agony this industry went through with C as it evolved from K&R to ANSI, with a rainbow of subtle gradations in between. For a number of years C was famously non-portable till the dust settled.

Java is a nice compromise, an OOP approach that reduces the complex syntax of C++ and offers many of the benefits of objects without some of the baggage.

Yet, already Netscape and Sun have proposed Java lites to remove some of its cryptic syntax. It's Deja Vu all over again.

I do think C is doomed in the long term. A language with some sort of intrinsic tasking is needed and inevitable. More OOPyness is needed. Perhaps stronger typing and bounds checking will help have the compiler/runtime pick up programmer mistakes. Is Java the answer? Maybe. We'll know in a couple of years.

Java's virtual machine offers a lot of fascinating possibilities, though at some cost. A VM can catch tough runtime errors, and can permit fast development, with smaller code. Perhaps the VM will help make Java a language of choice for safety-critical applications, where a failure is a disaster. We just don't know, now, how reliable it will be, as it's still so immature. Will it be appropriate for 500,000 line systems? Who knows?

One thing's for sure: no one language will satisfy all needs. Assembly will probably always be with us; C has a wonderful niche that it's hard to imagine going away. Java could fill other needs.

Killer Web

Java is a language in development. It's growing and changing in real time, as Sun and others experiment with real applications that satisfy real (as opposed to simply "cool") needs. Be sure that the language of today will evolve towards something different even in the course of the next year.

Though Java was originally conceived as an embedded lingo, it is finding its true home on the net. The net will ensure its success, unless Gates & Company manage to defuse this (horrors!) non-Microsoft invention by replacing it with yet another version of Basic. Standards and success in the computer industry are measured today by the size of the PC market. Any PC/Internet hit is, by definition, a success that spills over into all other computer arenas.

This is not a bad thing. The embedded x86 processors, like the 186 family, owe much of their ease of use to the wonderful tool chains (notably Borland and Microsoft's compilers) that survived the PC wars.

My fear, though, is that the PC market is such an irresistible force that there is no restraint of common sense. Things grow all out of proportion to value. Word processors are 30 Mb. Operating systems use every resource available and dreamed of. Compiler packages eat almost 100 Mb and come with hernia-inducing amounts of documentation.

As Java succeeds in this chaotic environment, compelling arguments will be made to enhance this feature and add that capability. The language will grow! and grow! and grow. Nothing constrains code/feature/standards bloat in the PC world, since the next, faster processor always but a year away, and hard disk space has vanishingly little cost.

Will Java lose the compactness so enticing to embedded developers? Will it become just another feature-laden language?

Infinite CPU power and memory solve many problems! but never cost. Your boss will surely go ballistic when, a month before shipments should begin, you suggest changing from an 8051 to a Pentium Pro.

There's little doubt that the inexorable forces of the PC industry will cause Java to expand, adding more features simply because they are possible, and to address "needs" that are perhaps only whims. Surely, the needs of the PC world are different than those of the embedded world, which may cause Java to drift in a direction that makes no sense for our small ROMed apps.

Until a firm ANSI standard is in place, and is stable, with few committees working on extensions (i.e., the enviable position C now enjoys), Java is a language in transition. Your code today may be useless tomorrow. The compiler that does such a wonderful job now may, in version 8.2, be so crippled and constrained by the then-current language definition that your code may become too big or too slow.

Hacker Heaven

I do have another fear with the philosophy behind applets, whether they are written in Java or COBOL. For a generation we've adhered to a sort of computer paranoia, limiting the applications we'll permit on our desktop computers. We've learned the perils of exposing our data to any potentially virus-ridden program.

Internet applets are a means to invite the whole world -- Mother Teresa to Harry Hacker -- to load and run programs on our machines.

It gives me the chills.

Sun et al assures us the Java is! or will be Real Soon Now! secure. Sure. Read the flood of CERT announcements about Java security flaws. With security an ever increasing concern, it seems odd we'd be so willing to let the world at large into our machines.

A year ago we started selling dial-up Internet access locally, and have found that it's a cruel digital world out there. Our UNIX machines are under more or less constant attack by (mostly amateur) hackers who fortunately know too little to be more than an annoyance. They generally can't defeat our security. With Java we invite these scum into our desktop machines, sacrificing many layers of security, in the hopes that only the Java Virtual Machine will protect us.

Embedded Java

For success in the embedded world, Java first and foremost needs a stable standard. Then it needs tools. Lots of tools. Any healthy industry segment is rife with dynamic, competing vendors, selling compilers, debuggers and the like. When Java spawns a big base of support products, the risk inherent in any narrowly supported product will diminish.

Embedded debugging today is built around source level debuggers. No matter what tool you use - emulator, ROM monitor, BDM, etc. - a source debugger is the tool that makes it convenient (or even possible) to debug C and C++ code. Java will not succeed without this. Until you can collect real time trace via an ICE or logic analyzer and show it in the original Java form, Java will be simply too expensive to use. Until Java-aware performance analysis tools and code coverage analyzers appear, it won't be an important factor in safety-critical systems.

Until RTOS vendors offer Java-bindings for their products, it cannot enjoy the (admittedly limited) software recycling success we see with C.

There's a lot of confusion now over whether Java will be a compiled or interpretative language - or both. An interpreted embedded implementation brings many benefits - small code and the possibility of Forth-like interactive development (really important in these short time-to-market days). A compiled version will run faster, almost a requirement for Java's success in real time applications.

Java's current implementations leave some serious problems for embedded systems. Apparently it's garbage collection scheme, once started, must run till completion. Bummer for hard real time deadlines!

One of Java's largest shortcomings is its newness. How can you do an embedded project when you don't know the language? Will you learn it by on-the-job training, using the next project as an experiment? What if you fail! will the project be doomed, perhaps costing the company a ton of money?

C took almost two decades to be commonly used in the embedded world. I think the reason is simple: until a large number of C programmers were available, no one was willing to risk their next product using this "new and risky" technology. As colleges cranked out C-adept programmers, companies inherited their expertise till a critical mass of C knowledge existed.

In college one writes a number of programs. Many are disasters! You learns from these, honing one's skills, until, after a couple of years you're reasonably competent. All that crummy code you wrote is sacrificial, tossed in the trash at the conclusion of the course. This is not an option in industry.

Adopting Java en masse (as the press seems to be promoting) before this level of competence exists, before we've had a chance to have some spectacular disasters in unimportant projects, is a mistake.

Will Java succeed? I hope so! The potential is exciting. Java on an 8051 could be really interesting for tiny applications. If coupled with an interactive development environment, perhaps using flash memories, we could crank out small systems in no time at all.

The question is: can you afford the risk? What is the compelling reason for taking this risk? Isn't C or C++ adequate until the dust settles?

My advice is to learn about Java. Play with it. Attend seminars. Become adept, as it may indeed be "the next great thing". But be conservative in your embedded projects. Don't bet the company on new technology just because it's new.

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: