In the struggle for the hearts and minds of desktop developers, Microsoft Corp and Sun Microsystems Inc are clashing over what technologies programmers will use to write Java applications. Sun admits the dispute is purely about marketing rather than legal issues, and says the firms are currently negotiating a way out of the dispute which […]
In the struggle for the hearts and minds of desktop developers, Microsoft Corp and Sun Microsystems Inc are clashing over what technologies programmers will use to write Java applications. Sun admits the dispute is purely about marketing rather than legal issues, and says the firms are currently negotiating a way out of the dispute which has lead to highly-placed executives from both companies engaged in some very public mud-slinging. At issue is what technologies a Java licensee must deliver to customers and whether it is all or some of what Sun supplies. The dispute first came to light when JavaSoft decided make to Java’s Remote Method Invocation API embrace The Object Management Group’s Corba IIOP protocol (CI No 3,193), which stands opposed to Microsoft’s DCOM, and ship it next to Java’s own Remote Method Protocol beginning probably with the next iteration of the Java Developers Kit. Microsoft insisted that it wouldn’t be caught dead using Java with IIOP, declaring IIOP only being good for hooking together different versions of chaos because different versions of Corba won’t talk to one another it and that it couldn’t be made to ship it under its contract with Sun. Since then, the dispute has escalated.
JavaSoft has created a set of Java Foundation Class (JFC) user interface libraries for programmers to write to; Microsoft of course is determined to keep developers firmly within the Windows camp and have them write applications which utilize its own Application Foundation Classes (AFC) that work with Java. Microsoft says it’s not legally obliged to deliver JFCs with its products. There are wider implications for the use of JFC versus AFC because the two are incompatible. Developers will have to choose to write applications using one or other mechanism – or to write separate versions for both. End users will require both sets of libraries on their systems to be able to run applications efficiently, effectively destroying Sun’s ‘write once run anywhere’ claim for Java. Sun, which at one time said its Java licensees have to ship the core part of Java, including the JFCs, now offers no comment on the matter. It says it’s sorry that Microsoft is talking about its Java contract in public and says the dispute centers on differing interpretations of the terms of Java contracts, details of which it won’t disclose. It previously claimed its Java contracts are the same for all licensees and that effectively Microsoft has no choice but to adopt the technologies in dispute. Sun recently announced the Java Performance Runtime for Windows, a binary runtime environment that it had touted back at JavaOne in April (CI No 3,210). It’s only a developer release, but it includes a Java virtual machine (JVM) and the JFC libraries. There’s a new JFC developer release due in August; early HotSpot dynamic Java compiler code is due in September; a JVM integrated with HotSpot is due in a JDK upgrade early next year. Meantime, for of all its bluster, OMG expects that Microsoft will be forced to adopt Corba in the next six to eight months. The availability of a cheap object request broker they can buy, market pressure (both developers and customers demanding they support it), and the fact that DCOM is a toy that will never scale or interoperate across anything other than Microsoft platforms (of which there will be as many as Unix at the rate they are going).