原創(chuàng)|行業(yè)資訊|編輯:龔雪|2014-12-11 09:57:20.000|閱讀 721 次
概述:Oracle已經(jīng)公布,Java9首個(gè)增強(qiáng)計(jì)劃集(眾所周知的JEPs),已經(jīng)確定會(huì)在2016年早些時(shí)候發(fā)布。
# 界面/圖表報(bào)表/文檔/IDE等千款熱門(mén)軟控件火熱銷(xiāo)售中 >>
Oracle已經(jīng)公布,Java9首個(gè)增強(qiáng)計(jì)劃集(眾所周知的JEPs) ,已經(jīng)確定會(huì)在2016年早些時(shí)候發(fā)布。
三個(gè)新的API已經(jīng)公布:
Process API在更新后能夠與操作系統(tǒng)中非JAVA相關(guān)的進(jìn)程互動(dòng),目前使用的API存在諸多限制,這迫使開(kāi)發(fā)人員經(jīng)常求助于本地代碼。這個(gè)API存在的主要風(fēng)險(xiǎn)是操作系統(tǒng)的異構(gòu)性,尤其是Windows。該API的設(shè)計(jì)需要適應(yīng)在不同的操作系統(tǒng)上的小型設(shè)備的部署工作,它還應(yīng)該考慮多個(gè)Java虛擬機(jī)運(yùn)行在同一個(gè)操作系統(tǒng)進(jìn)程的環(huán)境。這些考量將帶來(lái)一個(gè)更為抽象的API,這會(huì)增加設(shè)計(jì)的工作量。
新的HTTP客戶(hù)端,引入了對(duì)HTTP/2的支持。
現(xiàn)有API的問(wèn)題及實(shí)現(xiàn):
Https 2.0支持依賴(lài)于TLS ALPN (Application Layer Negotiation Extension),目前JDK中并不支持,Http 2.0規(guī)范本身還處于互聯(lián)網(wǎng)草案的形式,但在2014年它有望成為一個(gè)正式草案。
新的輕量級(jí)JSON API:它提供了一個(gè)輕量級(jí)的API用來(lái)處理和生成JSON文檔以及數(shù)據(jù)流,后者是基于已經(jīng)標(biāo)準(zhǔn)化的JSON支持,它是JSR 353的一部分。
還有三個(gè)JVM和性能相關(guān)的特性公布:
改進(jìn)競(jìng)爭(zhēng)鎖,旨在改進(jìn)當(dāng)線程競(jìng)爭(zhēng)訪問(wèn)對(duì)象時(shí)的性能。改進(jìn)競(jìng)爭(zhēng)鎖對(duì)現(xiàn)實(shí)世界中的應(yīng)用程序大有裨益,尤其是針對(duì)工業(yè)基準(zhǔn),如Volano和DaCapo。
這項(xiàng)工程將在以下與競(jìng)爭(zhēng)Java監(jiān)視器相關(guān)的領(lǐng)域,探索性能改進(jìn):
分割JIT編譯器的代碼緩存(在大型應(yīng)用程序上獲得更好的JIT性能)。將代碼緩存分解為獨(dú)立的段,每個(gè)段都包含特定形式的編譯代碼,目的是為了改善性能,并支持未來(lái)擴(kuò)展。
編譯代碼的組織和維護(hù)會(huì)對(duì)性能造成巨大影響,如果代碼緩存走錯(cuò)了方向,若干方面的性能退化實(shí)例將會(huì)獲悉。在引入多層編譯后,代碼緩存的地位變得極其重要,因?yàn)榫幾g代碼的數(shù)量比起不使用多層編譯,會(huì)有2-4倍的增長(zhǎng)。多層編譯也引入了一個(gè)新的編譯代碼類(lèi)型:instrumented編譯代碼 (異型代碼)。異形代碼具備與非異形代碼不同的屬性,其中一個(gè)重要區(qū)別是,異形代碼有一個(gè)預(yù)定義的限制性生命周期,與此相反,非異形代碼永遠(yuǎn)都會(huì)保留在代碼緩存中。
現(xiàn)存的代碼緩存是針對(duì)單一代碼優(yōu)化的,即只有一種形式的編譯代碼。代碼緩存被組織為一個(gè)獨(dú)立的堆數(shù)據(jù)結(jié)構(gòu),位于一個(gè)連續(xù)的內(nèi)存塊頭部。因此,具有預(yù)定義的限制性生命周期的異形代碼將與非異形代碼混合,并永久保留在代碼緩存中,這會(huì)帶來(lái)不用的性能和設(shè)計(jì)問(wèn)題。比如說(shuō),sweeper方法在掃描時(shí)將被迫掃描整個(gè)代碼緩存,即使其中一些實(shí)體從未更新,或存在非方法的代碼。
“智慧的”Java編譯器的深入開(kāi)發(fā),稱(chēng)之為sjavac,它支持并行和共享編譯,還包含一些其他特性。
由于存在各類(lèi)關(guān)于穩(wěn)定性和可移植性的問(wèn)題,sjavac在默認(rèn)情況下并沒(méi)有在JDK構(gòu)建腳本中使用,這項(xiàng)JEP的首個(gè)目標(biāo)是解決這些問(wèn)題,這牽扯到必須確保工具能始終在所有的軟硬件配置上產(chǎn)生可靠的結(jié)果。
總體目標(biāo)是要改善sjavac的質(zhì)量,使其成為一個(gè)通用的javac封裝,有能力編譯各種大型Java項(xiàng)目。
后續(xù)項(xiàng)目將繼續(xù)探索如何在JDK工具鏈中將sjavac分離出來(lái),如果可以的話(huà)。sjavac可能會(huì)成為一個(gè)獨(dú)立支持的工具,或是與javac集成的非獨(dú)立工具,或是其他。
最后,一個(gè)誘人的特性已經(jīng)在JEP 201中得到了承諾:模塊化源碼。這其實(shí)就是曾經(jīng)我們熟知的模塊化解決方案“Jigsaw項(xiàng)目”(最初目標(biāo)是Java 8的一部分)。
Jigsaw項(xiàng)目旨在為Java SE平臺(tái)設(shè)計(jì)和實(shí)現(xiàn)一套標(biāo)準(zhǔn)化的模塊系統(tǒng),并應(yīng)用于自身平臺(tái)中,繼而投入到JDK中。其最初的目標(biāo)是使平臺(tái)實(shí)現(xiàn)更容易擴(kuò)展到小型設(shè)備上,改善安全性和可維護(hù)性,改善應(yīng)用程序性能,并提供給開(kāi)發(fā)人員在面對(duì)大型應(yīng)用時(shí)一種更好的工具。
這項(xiàng)JEP是Jigsaw項(xiàng)目的第一階段的一部分,接下來(lái)JEP會(huì)將JRE和JDK的鏡像模塊化,之后再引入一個(gè)模塊系統(tǒng)。
在早期對(duì)源代碼進(jìn)行重新組織的動(dòng)機(jī)是:
原文鏈接: 翻譯: -
譯文鏈接:
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請(qǐng)務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請(qǐng)郵件反饋至chenjj@fc6vip.cn