When my dear friend Allan had major surgery a couple of years ago, I was thankful for the specialists who were able to meet his needs and provide him with critical care. The success of his procedure was absolutely dependent upon the exceptional skills of these specialists - without whom failure would have been certain. In software development, as in medicine, we have a need for specialists to help manage the enormous complexity that confronts us on a regular basis.

Object-oriented programming gurus have historically predicted the evolution of a thriving economy based on the sale of reusable software components, with expert vendors providing solutions for the specialty needs that arise in day-to-day general product development. In theory, at least, these reusable components would benefit us by reducing the time required to develop solutions, reducing the associated costs and risks and preventing us from having to reinvent the wheel every time we approach a programming challenge.

This theory, however, may not hold water in the Java economy. It's difficult to tell whether this market for reusable components is actually emerging in the world of Java technology.

Once upon a time there was a small company called "ORO Incorporated" that produced a truly excellent regular expression matching package for Java. They also produced a Java class library that implemented important Internet protocols such as FTP, NNTP, SMTP and POP3. Their implementation of the Internet e-mail protocols was available long before Sun's JavaMail API came out, even in early-access form.

There was also a company called JScape that produced a whole suite of developer class libraries, professionally packaged, supported and advertised. JScape also implemented support for Internet e-mail and other fundamental protocols that should have been genuinely useful for building the distributed, network-ready applications that are the supposed forte of Java. They were economically priced, reusable components - and source code was readily available if desired.

The other day I read on Usenet that JScape closed its doors and went out of business last November. I believe ORO disappeared from the scene sometime last summer or fall -Êmuch to the chagrin of many developers who subsequently expressed how much they relied on the ORO tools and valued them.

Apparently they didn't value them enough, at least not enough to make sure that ORO had sufficient economic incentive to remain in the business of producing them. JScape also tried hard but did not or could not succeed. I am sorry to see them go.

To some degree, both of these tool vendors were probably casualties of the Java wars - suffering irrecoverable economic downturns in a marketplace shaped by Sun's initial overhyping of Java and the ruthless Microsoft FUD campaign that followed. Ironically, true to the nature of our big-business economy, Sun and Microsoft have both increased dramatically in value during this time, but these two quality innovators of Java developer tools have perished.

The Java wars are not the whole story, however. Sun, as the platform provider and leader, is doing little to nurture this critical Java components market segment, and they may actually be suppressing it! In their attempt to have the Java core platform "be all things to all people," they may actually be preventing the normal, healthy growth of demand for specialty tools that could help propel Java to new heights.

In short, Sun has its fingers in too many pies - they have API-development initiatives in too many specialty areas. There is little incentive for specialists to invest in providing Java technology solutions if they must compete against offerings that will be available for free from Sun. Even though the Sun solution will typically offer less than what a real expert could provide, the combination of "free" and "from Sun" is a one-two punch that will knock out even the best contenders. I wouldn't be surprised if we see additional toolkit vendors close their doors or withdraw from the Java market this year.

It doesn't make sense for Sun to be in so many specialty areas either. The Java core platform has burgeoned beyond the point where Sun is able to support it effectively - but they still continue to expand. Hundreds of known bugs verily scream for attention, but Sun is too busy creating new ones to fix them! The situation would almost be comical if it weren't for the reality that it harms all of us who are trying to succeed with Java. If Sun would more narrowly focus its platform-development resources on perfecting the core of Java, then both Sun and the Java developer community would profit from a stronger foundation on which to build lasting success.

If things keep going on their present track, Sun may give a whole new meaning to the term "single-source supplier" - they'll be the only supplier of Java tools left. I encourage you to fire up the old HotJava browser if you need a reminder of what that could mean. Sun may produce great hardware, but their software undertakings often leave much to be desired. If Sun gets back to basics and makes the heart of Java faster and more reliable, then I have no doubt that top-notch experts will appear to meet the specialty needs of all sorts of innovative and demanding Java projects.