由于在微软的环境中使用Java虚拟机（JVM）引起Sun和微软的法律争议，Sun和微软于2001年达成解决方案，许多公司可能也面临着类似Y2K（千年虫）的问题。实际上，许多公司可能还不知道他们的风险，因为他们并不知道他们现在使用的技术属于哪一个安全级别。现在让我们来查找一下潜在的问题根源，看看使用什么方法可以减轻或者消除现有环境所存在的风险。
问题 解决方案的条款之一就是在2004年一月之前，微软将不能对其Java虚拟机版本的内容进行任何修改。如果你的企业已经使用了不是基于微软版本的Java虚拟机的Java解决方案，这项条款将不会对你有任何影响。但是，对于许多公司来说，他们的Java配置环境依赖于与早期Internet浏览器（IE）版本一起发行的JVM版本。对于这种情况，就应该开始考虑如何减轻未来可能出现的风险。
如果你什么都不做，将不会发现自己处于风险之中。微软已经从Windows XP中拆除了JVM，且在一年多的时间，不会与更新的IE或其它任何产品一起发布它。此外，微软已经对其当前（最近的官方发行版）的VM版本发行了安全补丁。但是，假设在2004年1月1日以后仍不允许微软对其安全漏洞进行修补，你所能够采取的最好的办法就是：现在对你的系统进行改变，不要对微软的VM有任何的依赖。怎么样才能保护自己呢？
降低风险的策略 在任何降低风险的策略中，第一步要做的是必须明白你对微软的VM的依赖程度，属于哪一个级别。例如：你是否已经使用Java编写了应用程序产品，而这些产品要求在服务端或者客户端有微软的VM？你的客户端工具中是否使用了微软的VM？在你已经发行或者安装的商业应用程序中，是否有服务进程或者运行在客户端的Java程序依赖微软的VM？许多公司都将发现一些自己并没有意识到的依赖关系。一旦发现了这些依赖关系，就应该开始制定过渡计划，并绘制移植路线。最后，开始移植并测试。从现在开始到2004年一月这短短的时间，这对IT部门的某些人来说是必须优先解决的问题。
降低风险的选择 在了解自己对微软的VM的依赖程度之后，对于如何降低风险可以有几种选择。第一种选择，也是最常采用的解决方案，是删除微软的VM而转向另外一个公司的Java VM。那些大量采用Java和J2EE技术的公司可能已经选择了非微软的VM，并且应用到其应用程序产品中。但是，许多既采用了微软的技术又采用了J2EE技术的公司可能仍然保留微软的VM。他们现在应该考虑降低风险的策略，包括使用其他公司的VM来代替微软的VM。另一种降低风险的策略是消除对任何版本的Java VM的依赖性。
对于依赖Java 程序的客户端应用程序，可以有两种方法消除对Java的依赖性。第一种方法，不使用Java 程序技术，而是使用其他的替代技术，如DHTML，Macromedia Flash或者其他客户端提供技术。第二种方法，微软已经发行了它的J＃浏览器控件（JBC）的beta 版，JBC允许公司将其现存的程序代码移植为J#.NET，并且使用.NET框架替代JVM 来运行客户端的应用程序。当然，对于这两种选择，要想有效的移植客户端程序的功能，你必须有权访问Java源代码。
如果你无权访问源代码，那么可以通过使用IE的安全区特性，这样至少可以降低一些客户端的安全风险。这些特性允许你对特定站点限制微软VM的使用，并禁止通常的Internet站点访问微软的VM或者潜在的滥用微软的VM。如果希望长期在客户端使用Java，那么要考虑或者将代码移植为另一种技术，或者用另一个提供商的JVM来代替微软的VM。
对于大多数在服务器上已经使用J2EE和Java技术的公司，他们通过其服务器工具提供商的推荐选择使用了JVM。如果在你的环境中，服务器安装的是微软的VM，你应该或者将应用程序移植到一个不同的JVM上，或者使用Visual Studio将应用程序从Java移植到.Net上，当然，这取决于你的公司选择的技术方向。
微软的支持 对于那些需要对其客户提供移植服务的咨询公司和软件开发商，微软将发行转换和移植工具以及程序和指南。MSDN.com是微软这些工具的主要发行机构。网站上已经提供一些工具的Beta版本格式。例如，微软最近发布了微软虚拟机转换指南，该指南提供了详细的各种不同的转换选择。为了帮助消费者理解他们在哪些方面对微软的VM有依赖，微软将针对微软的VM发布一个称为微软诊断的工具。
为了帮助消费者重新编译Java程序，使其能够在微软的.NET框架下运行，微软已经发行了J＃浏览器控件的Beta版，并将在今年秋天发行其最终版本。如果你的Java应用程序的数量太多，并且你的公司已经决定将其移植到微软的.NET上，你也可以考虑利用Java 语言转换助手2.0（JLCA），来帮助你将所有的Java应用程序全部移植为C＃语言。
