You'd Better Drop Microsoft's J++ Now
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Microsoft will stop distributing and maintaining Visual J++—along with all other products that use Microsoft Java Virtual Machine (VM)—on January 2, 2004. Blaming its abandonment of J++ on a January 2001 court settlement with Sun, Microsoft claims to be working to "ensure that all customers can migrate to an alternate solution." Several workarounds are now posted on Microsoft's Web site. Yet, with less than four months to go before January, some of Microsoft's other alternate solutions aren't even ready.
If you know where to look on Microsoft's Web site, you'll see Microsoft freely acknowledging that you need to start dropping J++ now. "If you are a developer who has used our developer tools to create Java applications, you may continue redistributing the Microsoft VM to your customers in accordance with the terms of the license agreement for those software development tools," says a Microsoft document called "Customer Fact Sheet On Removal of Java from Windows".
Microsoft goes on to say, "However, if you are using the Microsoft VM in your environments or developing software that uses the Microsoft VM, you should plan now to migrate to an alternate solution by January 2004. In addition, because we are not authorized by Sun to make fixes to address security vulnerabilities after January 2, 2004, you need to have a plan for disabling the Microsoft VM on machines in your environment before that time."
For dealing with J++ code, Microsoft is pointing developers in a kaleidoscope of different directions. According to Microsoft, you should do one of three things:
Migrate J++ code to C#—or, alternatively, to J#
Replace the Microsoft VM with a Java Virtual Machine (JVM) from an unnamed "other company"
Replace the functionality currently provided by Microsoft's Java code with other rendering technologies from either Microsoft or third parties
Meanwhile, to batten down against post–January 2 security holes, you'll need to lock down the Microsoft VM wherever it is already deployed. As of mid-August, specific instructions on how to perform this step were still forthcoming from Microsoft.
Case History
Back in 1997, Sun brought suit against Microsoft for $35 million, asserting that Microsoft had breached its licensing agreement by adding extensions that weren't Java-compatible. One factor behind the suit was Microsoft's decision not to include Sun's Remote Method Invocation (RMI) technology in MS products.
Under a settlement reached in January 2001, Microsoft was required to pay Sun $20 million, as well as to permanently stop using "Java-compatible" trademarks. The court also gave Sun the green light to end its licensing deal with Microsoft.
Microsoft got permission to keep using Java in products that already contained Java—or that were already being tested—over the next seven years. However, Microsoft's distribution rights were limited to the source code in Sun's Java Developer Kit (JDK) version 1.1.1. Also, the court held that after January 2, 2003, Microsoft can no longer fix any security holes or other critical bugs in its Java technology.
Meanwhile, in the first release of Windows XP, Microsoft disabled the JVM, offering an installation-on-demand feature instead. The download feature was geared to end users who wanted to run Java applets but who didn't have the JVM installed anywhere on their machines. Then, after a court ruling in an appeal by Sun in 2002, Microsoft decided to make the JVM available as part of Windows XP SP1.
In the appeal, the court agreed with Sun that the settlement's license agreement terms allowed Microsoft to distribute Java only with its OS instead of as a separate download. However, the court disagreed with Sun's contention that Microsoft should be compelled to carry Sun's Java technology.
After Windows XP SP 1, the JVM will not appear in any more Microsoft product releases, according to Microsoft officials.