Sun/Microsoft Lawsuit: It Doesn’t Matter
Ever since Microsoft licensed Java from Sun, we've heard lots of debate about how complete Microsoft's support would be. The strongest expression of that debate has been Sun's lawsuit against Microsoft, and plenty of people believe that the outcome of this suit will be significant.
The lawsuit has come to the conclusion of a preliminary stage, but what ultimately may happen in court very likely won’t matter at all. To see why, it's important first to distinguish between Java the language and Java the OS-neutral programming environment. Microsoft has pretty good support for Java the language, and although the lawsuit might conceivably force Microsoft to stop calling its product "Java," it's hard to imagine the company would drop support for Visual J++. No vendor that wants to remain credible can afford a move like this. Besides, Java is a great language for writing Windows and Windows NT applications, if only for the natural way it integrates with COM. Finally, Microsoft has sold lots of copies of Visual J++, and it would be unlike it to walk away from a profitable product.
Microsoft will never fully support the Java environment. Among the issues raised in the lawsuit are Microsoft's limited support for Java's Remote Method Invocation (RMI) technology and other aspects of the Java environment that aren't strictly part of the language itself. It is plausible that the courts can force Microsoft to completely support these relatively basic features.
Since the day Microsoft signed the Java contract, however, Sun and its partners have greatly expanded the technologies that make up the Java environment. In particular, they've defined the Java Platform for the Enterprise (JPE). JPE includes a number of Java-based interfaces, each of which can potentially be implemented on any operating system, and each of which has a corresponding native API in Windows NT. For example, Enterprise JavaBeans is JPE's analog to MTS; the Java Naming and Directory Interface (JNDI) is like Microsoft's ADSI; and Java Data Base Connectivity (JDBC) is much like Microsoft's ODBC.
Given that the purpose of JPE is to hide the APIs of any particular OS, what possible reason could there be for Microsoft to support these emerging Java standards? The JPE interfaces are perhaps today's major competitor to NT -- and eventually to Windows 2000 -- and it's seldom in a vendor's interest to support competing technologies. The Java hopeful might argue that by signing the original Java contract with Sun, Microsoft committed itself to supporting JPE. But it's just not plausible to believe that Microsoft would sign a contract that commits it to supporting whatever Sun defines Java to be, now or in the future.
Even if a court someday decides that Microsoft is obligated to support all of JPE -- a far-fetched outcome -- exactly how does one force a company to provide good support? In the unlikely event of this occurring, it's a certainty that Microsoft would support their own proprietary interfaces first and best, relegating JPE to second-class status.
Regardless of the lawsuit's ultimate outcome, here's some advice for organizations interested in using Java to build applications on Windows NT. First, if you're happy building apps that run only on Microsoft systems, but you'd like to use the Java programming language to build those applications, go ahead and use Visual J++. It's a good product, and it gets better and better as a tool for working in the Microsoft world. Having said this, though, I'd still argue that Visual Basic is a safer choice for NT enterprise development. VB is Microsoft's flagship language product, and so new innovations always seem to get the best support earliest in VB.
If you want to build scalable, enterprise-class Java applications that are not Microsoft-centric -- apps that aspire to run unchanged on any operating system -- expect to use non-Microsoft products. In particular, you'll want a Java compiler that's not as Windows-focused as Visual J++, and you'll also likely use a Java application server. Most Java app servers don't yet support a large fraction of the JPE interfaces, but they will. More important, virtually all of them target NT as a primary platform, which means they're tuned and tested to work well in the Microsoft environment.
Like many multivendor technologies, the JPE interfaces aren't as completely standard as users might like. Choose a Java application server carefully. Despite the vendor's claims of portability, it probably won't be trivial to move your application to a competing product. Still, for building reasonably portable, scalable, enterprise-worthy Java applications, a Java app server is probably the way to go.
Just don't expect Microsoft to provide one. Whatever results from their legal battle with Sun, a whole-hearted Microsoft embrace of the Java Platform for the Enterprise isn't in the cards. Instead, look for Microsoft to provide good support for building Windows and Windows NT applications in Java, and as little support as possible for running those apps on other systems. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at [email protected].