由於在微軟的環境中使用Java虛擬機（JVM）引起Sun和微軟的法律爭議
Sun和微軟於
年達成解決方案
許多公司可能也面臨著類似Y
K（千年蟲）的問題
實際上
許多公司可能還不知道他們的風險
因為他們並不知道他們現在使用的技術屬於哪一個安全級別
現在讓我們來查找一下潛在的問題根源
看看使用什麼方法可以減輕或者消除現有環境所存在的風險
問題 解決方案的條款之一就是在
年一月之前
微軟將不能對其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和J
EE技術的公司可能已經選擇了非微軟的VM
並且應用到其應用程序產品中
但是
許多既采用了微軟的技術又采用了J
EE技術的公司可能仍然保留微軟的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
對於大多數在服務器上已經使用J
EE和Java技術的公司
他們通過其服務器工具提供商的推薦選擇使用了JVM
如果在你的環境中
服務器安裝的是微軟的VM
你應該或者將應用程序移植到一個不同的JVM上
或者使用Visual Studio將應用程序從Java移植到
Net上
當然
這取決於你的公司選擇的技術方向
微軟的支持 對於那些需要對其客戶提供移植服務的咨詢公司和軟件開發商
微軟將發行轉換和移植工具以及程序和指南
是微軟這些工具的主要發行機構
網站上已經提供一些工具的Beta版本格式
例如
微軟最近發布了微軟虛擬機轉換指南
該指南提供了詳細的各種不同的轉換選擇
為了幫助消費者理解他們在哪些方面對微軟的VM有依賴
微軟將針對微軟的VM發布一個稱為微軟診斷的工具
為了幫助消費者重新編譯Java程序
使其能夠在微軟的
NET框架下運行
微軟已經發行了J＃浏覽器控件的Beta版
並將在今年秋天發行其最終版本
如果你的Java應用程序的數量太多
並且你的公司已經決定將其移植到微軟的
NET上
你也可以考慮利用Java 語言轉換助手
（JLCA）
來幫助你將所有的Java應用程序全部移植為C＃語言
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19373.html
