由于在微软的环境中使用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＃语言。