Imagine Henry Ford developing the first widely available automobile. He was a pioneer, engaged in the most exciting new industry of the time.

Imagine how frustrated he must have been. Where would drivers buy gas? Were the wrenches and screwdrivers advanced enough to build the cars? Would the cars hold up on the variety of roads out there? How would he ship the cars? And... would anybody buy them?

Nearly 100 years later, Java developers are pioneers all over again. It is an exciting time, but there are new obstacles to deal with. Instead of wrenches and screwdrivers, we use compilers and debuggers. Instead of gas, we use the AWT and JFC. And instead of roads, we run our programs on a variety of Java VMs. And we're still wondering what the right market is for our new software.

For Java developers, all phases of product development are complex. While native developers only need to cope with making their code work with mature compilers and APIs, Java developers must tame nascent technologies at every stage of development. When our software doesn't work, we can't be certain if we've coded something wrong, the compiler generated bad output, the APIs have bugs or the Java VM has an incompatible implementation.

Take Java VMs as an example. VM vendors are juggling features and compatibility, to the growing frustration of developers. Every VM does things differently, whether it's the implementation of the Abstract Windowing Toolkit or security management. These inconsistencies make it difficult to achieve the "write once, run anywhere" promise.

Current compilers and integrated development environments add to the frustration. The latest IDEs often lack many features of their native counterparts and fail to integrate the newest Java technologies. How many IDEs implement JavaBeans introspection, presenting a "customizer" if available, and linking events to listeners? And how many have integrated debuggers that can handle complicated, multi-threaded code? Not many.

But the situation is improving. Sun's recently announced Java Porting Centers hopefully will establish a common codebase for Java VMs and improve compatibility. It's still not enough though, and we should insist that all Java VMs be 100% compatible with each other.

The Java APIs are improving as well. While the AWT was quirky and needed adjustment for each platform's specific graphical user interface, the Java Foundation Classes eliminate most inconsistencies - a giant step in the right direction.

But Java tools still need improvement. Java developers shouldn't have to work with compilers that crash or IDEs that only partially support the Java APIs. Compilers must work perfectly every time. I can't tell you how many times I've seen people resort to the command line JDK tools since their "paid for" tools crash or are incompatible. It just proves the point that compatibility is far more important than features.

As Java developers, we need to help send this message to the Java VM vendors, IDE vendors and everyone else working with Java. We need to insist on core functionality with robust compatibility and completeness - before we ask for cool new features.

It's a whole new industry - we should treat it that way. Just imagine if the first Fords had saddles for seats and ropes instead of parking brakes... we'd probably still be wearing spurs in our fancy new sports cars.