It's a funny thing, public opinion and the media and how they determine the direction of so many things. Presidential elections, foreign policy, the stock market, and yes, even Java. Java has survived 1997, but its coat doesn't have the same shine and sheen that it enjoyed in 1995, where it was the latest buzzword and managers were looking for Java developers with at least five years of experience. It's 1998 and in order for Java to make it into the 21st century, it needs a new infusion of both marketing and material.

Third party component vendors, such as Stingray Software and Rogue Wave, will continue to play a major role in Java's evolution. By filling in the gaps of the JDK, component vendors allow developers to go farther, pushing Java into a more serious contender as the language of choice. While the component vendor role is high in importance (even higher as Java is still a relatively new language), JavaSoft needs to recognize and encourage the vendors' efforts even more than has been done to date. (One can look to the well-established Visual Basic component marketplace to see how Microsoft started a cottage industry through outstanding developer relations.) Without establishing a mature developer relations group, many third-party vendors come and go and, in general, create a shaky market. JavaSoft needs to recognize their role and offer more support for those who are trying to bring Java to the next phase.

Another issue that is hurting the adoption of Java is the deployment of APIs and JDKs from Sun. It seems not a month goes by without an announcement of a new API set, whether it's something outstanding like the JavaBeans and JFC API or something obscure like the Java Input Method and Java Advanced Imaging API. It's as if Sun regards these APIs as spaghetti noodles, throwing them against the wall and seeing what sticks. The fallen noodles are determined by the Java community response and, as a fallen noodle, the time from announcement to deployment is extreme, either taking over a year or totally dropped. This causes a lot of uncertainty within the Java community and also hinders Java's growth.

After 2+ years of developing client-side components, the most daunting issue facing Java developers today is the QA issue. One of the main reasons that Java took off (if not the main reason) was that you could write a program in Java and then it would run on any computer that had the JVM installed. The impact of this statement is so overwhelming, it almost deserves being repeated. However, with the advent of platform-specific and vendor-specific JVMs (meaning a vendor, once licensed, could build a JVM following certain specifications), the "Write Once, Run Anywhere" slogan has changed to "Write Once, Test Everywhere." A typical QA engineer working on a Java client applet/application to be tested in multiple environments now has the non-enviable task of testing under multiple operating systems, each of which might have multiple JVMs under them (with different versions of those JVMs too!). While we've consistently been told that Java is a young language and that things will get better, two years has proven otherwise. While technologies such as Project Java Activator might help in the future, not every Java developer will be able to assume that their target audience will conveniently have (or be allowed to have) this technology enabled.

It is as Charles Dickens wrote, "It was the best of times, it was the worst of times." These are the times that will try Java developers' resolve. 1998 will be a pivotal year for Java. It is up to Sun and Java developers everywhere to deliver the killer apps and tools that will maintain Java's name and carry it into the 21st century. Otherwise, Java will become a fond memory and a display at the Smithsonian detailing how Java started with a bang, but ended in a murmur.