Java SE Runtime Environment
- 軟件授權： 免費軟件
- 軟件類型： 國產軟件
- 軟件語言： 簡體中文
- 更新時間： 2023-11-17
- 軟件評分：
- 軟件大小： 160MB
- 應用平臺： WinAll
軟件介紹 下載地址
Java SE Runtime Environment官方版是一款Java平臺的標準運行環境。Java SE Runtime Environment官方版包含了Java虛擬機(JVM)和Java類庫等關鍵組件讓用戶可以運行Java應用程序，并在計算機上體驗到豐富多彩的Java應用世界。Java SE Runtime Environment官方版還提供了Java更新機制，使用戶能夠及時獲取最新的安全補丁和功能更新。
Java SE Runtime Environment基本介紹
1、Java SE Runtime Environment 共享類庫需要在GAC(Global Assembly Cache)中注冊，注冊過程比較復雜，首先要用工具生成公開/私有密鑰對，然后結合密鑰和類庫版本號連編，最后使用工具注冊到GAC中好以后,會被放在"C:Winntassemblygac類庫的名稱空間版本號"目錄下，不同的類庫版本在注冊的時候會按照版本號分開放置：
某類庫1.0版本 C:Winntassemblygac名稱1.0名稱.dll
某類庫1.1版本 C:Winntassemblygac名稱1.1名稱.dll
2、可以同時存在一個類庫的n個版本，至于在程序中用哪個版本，在程序的配置文件中聲明，CLR會根據聲明來調用相應的版本的類庫。我覺得.Net實現方法未免太復雜了一些，將所有共享類庫都塞到一個系統目錄下，并且同一個類庫還有n個版本，將來.Net第三方開發的類庫逐漸豐富起來以后，.Net類庫的GAC也會越來越龐大，會不會也搞得和Windows注冊表一樣難以維護?軟件發布到服務器上的時候，類庫要再注冊一次，服務器會逐漸形成一個龐大的樹狀的GAC，GAC里面存放著組件的n個版本。試想經過一段時間之后，C:Winntassemblygac目錄會越來越龐大，有的組件甚至有n個版本都放在那里，你又不敢隨便刪除，不知道是不是有程序需要使用，我不明白MS為什么要把這么簡單的事情搞到這么復雜?
討論：全局程序集緩存不會是無限大的，所以“將來.Net第三方開發的類庫逐漸豐富起來以后，.Net類庫的GAC也會越來越龐大，會不會也搞得和Windows注冊表一樣難以維護?”這是杞人憂天。原因如下：第一是操作系統的生命周期一般不會是無限長的，而且越來越短，Windows為證，同時.Net Framework也在不斷更迭，在十年左右的時間里，全球的程序產量是有限的，高質量的第三方開發的類庫更是有限，需要注冊到GAC的就更少了。
Java SE Runtime Environment注意事項
1、共享類庫需要在GAC(Global Assembly Cache)中注冊，注冊過程比較復雜，首先要用工具生成公開/私有密鑰對，然后結合密鑰和類庫版本號連編，最后使用工具注冊到GAC中好以后,會被放在"C:Winntassemblygac類庫的名稱空間版本號"目錄下，不同的類庫版本在注冊的時候會按照版本號分開放置：
某類庫1.0版本 C:Winntassemblygac名稱1.0名稱.dll
某類庫1.1版本 C:Winntassemblygac名稱1.1名稱.dll
2、可以同時存在一個類庫的n個版本，至于在程序中用哪個版本，在程序的配置文件中聲明，CLR會根據聲明來調用相應的版本的類庫。我覺得.Net實現方法未免太復雜了一些，將所有共享類庫都塞到一個系統目錄下，并且同一個類庫還有n個版本，將來.Net第三方開發的類庫逐漸豐富起來以后，.Net類庫的GAC也會越來越龐大，會不會也搞得和Windows注冊表一樣難以維護?軟件發布到服務器上的時候，類庫要再注冊一次，服務器會逐漸形成一個龐大的樹狀的GAC，GAC里面存放著組件的n個版本。試想經過一段時間之后，C:Winntassemblygac目錄會越來越龐大，有的組件甚至有n個版本都放在那里，你又不敢隨便刪除，不知道是不是有程序需要使用，我不明白MS為什么要把這么簡單的事情搞到這么復雜?
討論：全局程序集緩存不會是無限大的，所以“將來.Net第三方開發的類庫逐漸豐富起來以后，.Net類庫的GAC也會越來越龐大，會不會也搞得和Windows注冊表一樣難以維護?”這是杞人憂天。原因如下：第一是操作系統的生命周期一般不會是無限長的，而且越來越短，Windows為證，同時.Net Framework也在不斷更迭，在十年左右的時間里，全球的程序產量是有限的，高質量的第三方開發的類庫更是有限，需要注冊到GAC的就更少了。
Java SE Runtime Environment更新介紹
- “G1 增強功能 (JEP156): 限制了長期停頓的可能性，釋放系統資源。G1依靠全面的垃圾收集(Garbage Collections)以執行分類卸載，并減少任何其他的關鍵性操作。
- Java Flight Recorder (JFR)的動態支持: 為了簡化Oracle Java SE Advanced使用性，JFR現在能夠命令行或Java任務控制(JMC)中的動態啟動，無論其是否是原始的啟動參數都可實現。JFR的動態啟動讓用戶無需停止工作也能解決生成問題。
- 增強本地包裝程序：允許開發人員在不安裝現有的Java Runtime的基礎上創建本地應用。這些獨立的應用能夠在如Mac應用商店的區域內進行部署。應用開發人員可全面控制運行時間和應用輸入口。
- 新的日期更新工具：這個工具能夠從IANA時期注冊表數據庫中消耗“初始”的數據(tzdata)規則，并把其轉換成JRE所需要的格式。這讓用戶通過升級最新的IANA就能同時實現JDK/JRE時區的更新。
- 支持Nashorn：該版本擁有大量的Nashorn優化功能，包括對動態語言的支持等等。同時新版本還增加了Nashorn 分類過濾器，可以通過全新的過濾界面從JavaScript編碼中對Java分類進行精細管控。
- 針對內存壓力的JVM反饋: “內存壓力” 是代表系統總體內存使用(RAM)的一個特性。這個新特性可以在部署多個JVM的系統中降低內存的消耗，并將其在每個JVM內的大小控制在一定的范圍之內，避免因內存不足而引發的問題(OOMEs)。
- Java 任務控制 5.5 (JMC): 這個工具現在已經和JDK 8u40進行捆綁。基于Eclipse 4.4，JMC 5.5包含了現在已經簽署的插件，并擁有默認隱藏Lambda 格式的隱藏方式。
- Lambda 格式的減少和緩存 (JEP 210): 這個增強功能可以為應用減少所需的內存足跡，同時提高了動態語言的性能。
- 本地內存跟蹤擴展性 (JEP 195): 這個功能已經得以提升，讓其運行時不會產生顯著的性能影響。同時，該功能讓用戶可以自行診斷Java虛擬機(JVM)內存泄露。
- 增強SHA算法的加密性: SPARC類型系統的性能已經得到提高，這些系統在網絡信任中通過簽署證書而被大量使用。SHA性能對互聯網安全很重要，因為瀏覽器已經開始使用計算更昂貴的SHA-256版本或者更高版本，SHA-1正在逐漸被淘汰。
新推的JavaFX特點和增強功能包括：
- 能夠在Mac OS X上實現JavaFX堆棧現代化(JEP 206)：JavaFX媒介堆棧已經從不適用于QTKit和 Quicktime遷移到更新的AVFoundation 架構中, 全面適配Mac OS X。 該功能幫助使用JavaFX媒體堆棧的開發人員有機會在Mac應用商店上發布他們的應用。
- JavaFX 訪問性 (JEP 204)：現有的JavaFX控制功能已經得到增強，并為開發人員提供了公用的API，讓其可以編寫自己的訪問控制程序。
- 當前的Java SE版本可用于一般計算使用，在Oracle網站上無需付費。如欲獲取，終端用戶可訪問這里，開發人員可訪問
蘇公網安備32032202000432