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