About two years ago a colleague of mine named Joe leaned over my cubicle wall and said, "Hey, I just downloaded this new language called Java. It's pretty cool!" At the time I can't remember being very excited about another programming language. I was a PowerBuilder maven and Joe was up to his eyeballs in C++. That probably accounts for some of my disinterest and Joe's initial drooling (sorry, Joe, but you did). Two years and one large-scale Java project later, I'm as much a convert as Joe.

That doesn't mean I want to rebuild everything that's ever been written in Java, nor does it mean I think PowerBuilder's obsolete (or C++ for that matter). I recently attended a conference where a technical representative from Sun was discussing Java for the enterprise. He asked, "Where should we use Java?" The answer was most appropriate: "Where you need it."

There's nothing a client hates more than an "it depends" answer. Unfortunately, it's often the truth. So it is with this answer. Where you're going to use Java depends on your needs and strategic direction. Should you use Java everywhere? Almost without a doubt, no. There are things Java is good at and things Java is not good at. There are also practical considerations, such as corporate infrastructure, that have nothing to do with Java's capabilities but impact where Java is and is not practical.

As an example of what's not practical, look at Corel's attempt to re-create its office suite in Java. In theory, Java is as suited for this as any language, more so than some with strong multitasking. But this was not the right place for Java. For one thing, you need every ounce of speed on a machine to make these overprogrammed suites perform well. JIT compilers notwithstanding, native code is still faster right now.

Even worse, you know someone would get the bright idea to host this in a browser. Why buy a thousand copies when you can access a single copy over the LAN? It'd be a tossup as to who would shoot that guy first - the network administrators who were dealing with network overload or the users who were waiting hours for their new, "improved" software to load.

Probably the biggest lesson that needs to be learned is that Java is part of an architecture, not an architecture unto itself. I hear companies saying, "We've got to go to Java," and I can understand their frustration and desire. The Internet has turned the safe, known world of client/server on its ear, and the closest thing to a standard that most of us can find is Java.

That's great. I'm all for Java being the language of the Net. It's compact, it's elegant and it's fun to program in. The problem is that you can't simply swap Java for whatever language you've been doing two-tier development in and expect to have a solution. For one thing, JDBC is still not as far along as ODBC or native drivers. For another, it's harder to provide the same rich GUI, at least on Windows platforms. Love it or hate it, Windows is still the overwhelming desktop today, and we need to be able to build better looking Java apps if Java is to become a dominant force on those desktops. Some of this is due to the browsers rather than to the language itself. I have to applaud the people who put HTML together as a document language, but as an application environment it leaves a lot to be desired.

So what do we do? It's pretty simple really. We need to put Java where it belongs. It's not the only tool we have, and we must have good reasons for selecting it over other languages and products. At the same time we need to push for improvements in the browsers and compilers, and hope that a JavaOS will actually make sense, both from a programmatic and, in an era of $700 PCs, an economic sense. Meanwhile, I need to call Joe and tell him he was right. I hope he doesn't rub it in.