While the Open Source Business Conference 2004 was taking place in San Francisco, Sun executives were touring the East Coast to deliver a progress report on various software initiatives the company has undertaken to counteract the toll exacted over the last few years by the x86 architecture, Linux, and, on the Java front, IBM.

However, third-party mass market Java applications (the third of the three components needed for a platform's ecosystem to thrive) were slow in coming. Despite a trifecta of opposing forces that involved the confusion introduced by Microsoft's embrace-and-extend version of the desktop JRE (and the subsequent Sun vs. Microsoft lawsuit), performance problems associated with runtime environments on 1990's-class systems, and the dot com bust, the Java ecosystem endured a perfect storm.

Java's loss of momentum has left the Java developer community idling at around 3 million for almost four years. Unfortunately, the slump lasted long enough for the one company most threatened by Java - Microsoft - to respond with a similar technology (.Net) that many IT managers now view as a credible middleware alternative. (This is especially true now that Java- and .Net-based systems can interoperate thanks to Web services-related protocols such as the SOAP and XML.)

The situation has left IBM and Sun with a mutual interest in limiting the penetration of .Net while growing the number of Java programmers. "We think there's about 10 million [software developers] on the planet," said Sun's Schwartz. "We want to get the number of folks who are Java developers from 3 million to 10 million." About one third of the open letter to Sun from IBM's Rod Smith was devoted to growing the number of Java developers or applications.

Although IBM and Sun may share the goal of putting Java back on a growth path, the two companies have exceedingly divergent views on how to accomplish this task.

IBM believes that open sourcing the Java specification will propel Java to Linux-like levels of popularity. "IBM is a strong supporter of the open source community, and we believe that a first class open source Java implementation would further enhance Java's position in the industry by spurring growth of new applications and encouraging new innovation in the Java platform," said Smith. "[An open source implementation of Java] would open a whole world of opportunity for new applications and growth of the Java community. In addition, this would accelerate the growth and adoption of technologies that are built on Java and are critical to our customers today, including Web services and service-oriented architecture."

Schwartz, however, looks at one of the nasty side-effects to Linux being open-sourced without the a governing body like the Java Community Process and sees a harbinger of things to come should Sun hand Java over to the open source community. "Compatibility is the supreme priority above all else because developers want freedom of choice," said Schwartz. "[They want to] write their applications to one server and have them run on all servers. Write to one desktop, and have their apps work on all desktops. That's been our priority." As overseer of the JCP, Sun can and would veto any movement within the organization that threatened compatibility.

Can Sun really afford to ignore the open source model , which, along with Web services, has created a new and fast moving technology ecosystem? Especially now that Microsoft has had time to catch up with .Net? Schwartz thinks so. Saying that Java was once an antagonist to Web services, Schwartz admitted to the tactical error Sun made by failing to embrace Web services sooner, but he claims the company has recovered. "Now, Java and Web services are synonymous," said Schwartz. To prove it, he pointed to Sun's recently released Application Server 8, a freely deployable Java 2 Enterprise Edition-based (J2EE) application server that runs on Solaris, Windows, and Linux. According to Schwartz, it is the first product to pass the official litmus test for Web services interoperability (WS-Profile) in its entirety.

Whereas Sun's expeditious support of Web services should certainly be regarded by the Java- and Web services-interested communities as a welcome change, converting millions more developers to the Java persuasion is a daunting undertaking. If, as Schwartz said, there are seven million non-Java developers scattered around the globe, a lot of them must be working on Windows or .Net. Schwartz is aware of this fact, but I'm not sure if he has a precise picture of who these developers are or what they're doing. In describing one of the segments he's after, Schwartz said, "Getting from three to ten million isn't going to happen when [those developers] have to whip up code editors and understand concepts that are relatively sophisticated. It will happen when we bring the tools down to a level that enables folks like advanced business analysts who are using Visual Studio into our community."

Schwartz is alluding to one of Java's key weaknesses-for anyone but computer science majors, it's unapproachable. Most Java development tool vendors have been working to correct this accessibility problem.

The thinking is that if the graphical development tools can make Java more accessible to mere mortals, then more of them will become fervent practitioners of Java. The question in my mind is, of the seven million "developers" who Sun is targeting, how many of them are in the Microsoft world and how many are business analysts using Visual Studio. Probably not many.

However Schwartz, like most toolmakers, is also chasing after business analysts who are developers, but just don't know it yet. Indeed, in the last year, I've seen more tools- such as Sun's Project Rave - that promise to one day turn business process experts into drag and drop coders. After seeing these tools, it's hard to argue against the contention that if programming is made easier, more people will be able to develop or modify applications. What I can't imagine, at least in enterprises (where business process people and analysts work), is this sort of "programmer" being influential enough to affect the software infrastructure decisions such as whether to use Java or .Net.

Instead of the ease with which a business analyst can create an application, the more heavily weighted criteria to affect the .Net vs. Java decision will have to do with mission critical questions like availability, scalability, security, performance, flexibility and total cost of ownership. These are issues that also require decisions at the operating system and hardware level of the stack. Against that backdrop, until Microsoft releases versions of .Net that run (and run well) on operating systems other than Windows, this is where Java has the most to offer.

In addition to Java's readiness for mission critical applications (at least on certain operating systems), IT shops have an incredible range of choices when it comes to assembling the underlying application server, hardware, and operating system stack. Whereas this ecosystem brings out a lot of innovation through competition amongst the various hardware and software players powering Java applications, the competition to power .Net applications is primarily at the hardware level, with Intel- and AMD-based systems. In this respect, Sun's prioritization of compatibility over all else when it comes to Java serves IT decision makers well. But those decision makers aren't the business analysts. They are the IT professionals who are providing the business analysts with the enterprise-worthy software infrastructure they need to get their jobs done.

Is it worthwhile for Sun to attempt to convince business analysts and other non-programmer types that Java is the way to go? For two reasons, yes. To the extent that IT departments provide business analysts with Java-based infrastructures, the last thing that Sun and its Java partners can afford is having that all important foot taken out of the datacenter door, allowing it to be replaced by Windows. In addition, a small slice of power users might venture into some sort of Java-based desktop application development. Schwartz claimed that there's been a resurgence of interest in Java on the desktop, an area where such power users have some discretion when choosing amongst development platforms.

But even here, Sun's strategy is a little weak. For drag and drop programming to work, the programmers need objects that can be dragged and dropped. Unless these objects were built by the programmer from scratch (in which case, we're not talking about the sort of mortals that Sun is looking to recruit), such objects are graphical abstractions of the functionality found in the operating system and applications to which the system has access (either locally, on the enterprise network, or even on the Internet).

Perhaps one day, when the directories and discovery capabilities are fully baked into Web services development tools, the Internet will offer a sea of objects that are open for use (perhaps for a fee) by business analysts and the like. But today, given Microsoft's dominance of the desktop, most if not all of the canned functionality to which these programmers currently have access is in Windows, Microsoft Office, and increasingly, the collaborative infrastructure found on the local area network that's powered by server-based offerings like Microsoft's SharePoint and BizTalk.

For Java to play a role in the discretionary development of desktop applications by time-constrained business people, it will not only need to be drag-and-drop friendly, but it will need access to the canned facilities that are currently found (or accessible) through the local system. If business analysts are interested in using products like Visual Studio, then it's probably because of how Visual Studio makes child's play out of working with these existing facilities. Writing applications in Java that take advantage of the functionality found in Windows-based applications is possible with third-party JRE-Windows bridging tools like iHub from Halcyon Software, J-Integra from Intrinsyc ] and Desiderata Software's EZ JCom, but Sun is not very enthusiastic about the bridging approach.

When I challenged Jonathan Schwartz about this, he pointedly answered that these "are not the developers we're after." So, is Sun pursuing all of the 10 million developers it estimates to be alive, or not?

In the same way Sun eventually embraced the bi-directional highway that Web services has paved between Java and .Net, my sense is that the company will have to endorse the same sort of connectivity on the desktop if it's really serious about winning over existing Visual Studio developers as well as current and future drag and drop "convenience store" developers. Today, companies like Intrinsyc and Desiderata emulate this direct bridging by layering Microsoft's distributed COM (DCOM) over remote procedure calls (RPCs) or working through JNI.

Tomorrow, with all the idle horsepower found on our PCs, running one Java and one .Net application server side-by-side in a way that facilitates intra-machine Web services-based access between local Java and Windows applications will be a no-brainer. Desiderata founder Mukesh Prasad believes that a recent increase in new orders being entered through the company's Web site reflects a wave of new interest in bridging the gap between Java and Windows.

It's a wave that Sun should ride. If Sun doesn't promote the idea, you can rest assured that a company like IBM (also working hard to make Java more approachable) will probably do it. While Sun may not be interested in winning over the aforementioned convenience store class of Microsoft developers, the company is apparently interested in capturing Office macro developers. During the briefing, Schwartz let slip news about a forthcoming macro conversion tool that targets users of MS Office who are interested in moving to Sun's StarOffice, but are prevented from switching because of the time they've invested in writing MS-Office macros that automate spreadsheet, database, and word processing tasks. Unfortunately, the tool converts the scripting language behind Office (Visual Basic for Applications) to StarBasic rather than Java, even though Java can be used to automate StarOffice.

But even if it did convert the macros to Java and even if Sun were successful at recruiting non-traditional developers into the Java fold, I'm still not sure that these are the kind of developers who will get the virtuous cycle behind the Java ecosystem spinning again. Cranking that up will more than likely require third-party turnkey applications that users can download or buy and install on their Java-enabled systems. Given Sun's emphasis on compatibility across all implementations of Java, the ecosystem is ready-made for some mass market applications that can run across a variety of dissimilar systems. In some respects, that's been Sun's biggest challenge--finding the killer Java application (for Java clients) that makes the JRE a must have.

Right now, that killer application could be for mobile Java.

Had the brouhaha between Microsoft and Sun over Microsoft's extended version of the Java Virtual Machine for Windows never existed, we might have had a few killer apps on the desktop by now. For now, desktop Java is stalled (to the benefit of Microsoft), and we're still waiting. Fortunately for Sun, there's little or no chance of Microsoft interceding in the handheld community the way it did on the desktop. In fact, if the number of Java-enabled handsets in the market hasn't already made Java the most widely deployed computing platform in the world (surpassing Windows, Linux, or anything else on any type of system), it will soon.

Nokia alone is manufacturing tens of millions of Java-enabled phones, and Motorola, Siemens, and Sony Ericsson are supporting Java in their handsets as well. By virtue of a newly upgraded Java specification for handhelds (MIDP 2.0), most of the existing barriers to the portability (across handsets) of mass market Java-based mobile applications have supposedly been dropped and the J2ME ecosystem (Java 2 Mobile Edition) seems to be well along its way. The platform is in the mass market, applications have started to roll out, and developers and wireless carriers are looking for ways to capitalize on the installed base of mobile Java Virtual Machines.

In terms of enterprises where client-side Java has been a bit dormant, the sudden explosion of Java on the mobile scene may end up having a wag-the-dog effect on the desktop and server versions of Java. For example, with Java going into so many handhelds (and supporting both PocketPC and PalmOS), enterprise application developers are realizing that Java-based clients represent the largest target in the mobile community. Additionally, for enterprise end users, the ubiquity of J2ME and MIDP 2.0 reduces the likelihood that someone from the IT department will be telling them what cell phone to buy if they want access to certain corporate applications.

Finally, if success on the mobile front has any sort of drag effect on the enterprise, Sun's problem won't be recruiting millions of programmers. It will be keeping up with them.

You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.