翻譯官方文檔，删除部分可忽略。
譯者：坤谷，井桐，激酶
相容性是一個複雜的問題。 本文介紹了java平台潛在的三種不相容問題：
源碼： 源碼相容性問題關注java源代碼轉換成class檔案是否相容，包括代碼是否仍然可編譯。
二進制： 在java語言規範中，二進制相容性定義為：“類的改變是二進制相容的（或者不破壞二進制相容性），是指如果改變前的類的二進制在連結時沒有錯誤，那麼改變後的類在連結時仍然沒有錯誤。”
行為 ： 行為相容性包括在運作時執行的代碼的語義。
欲了解更多資訊，請參閱openjdk的開發人員指南 中，相容性的種類一節。
下面的相容性文檔跟蹤相鄰的java版本之間的不相容。 例如，這個相容性文檔隻報告的java se 8和java se 7的不相容，而不是以前的版本。 要檢查的java se 8與早期的java版本的不相容性，必須按順序跟蹤一下不相容性溫的。
java se 7和jdk 7的相容性
jdk 6相容性
j2se 5.0不相容問題（自1.4.2）
除了下面列出的不相容問題，java se 8與java se 7是二進制相容的。 除了提到的不相容，java se 7編譯的類檔案将在java se8正常運作。而java se 8編譯的類檔案将無法在早期版本的java se運作。
java se 8包括新的語言功能和平台的api。這些都在源檔案中使用，這些源檔案不能在早期版本的java平台中編譯。
一般情況下，源碼相容性政策是避免引入的源代碼不相容問題。 然而，實作java se 8的功能所需的更改可能導緻代碼無法在java se的7編譯。見java se 8和java se 7之間的不相容性和jdk 8和jdk 7之間的不相容性。
deprecated api僅用于與早期版本的相容性支援。除非打開<code>-nowarn</code>指令行選項，隻要使用了deprecated api，javac編譯器就會生成警告資訊。 建議應用進行修改，以杜絕使用deprecated api。
<code>sun.*</code>包的 一些api在發生了變化。 這些api不供開發人員使用。 開發人員導入<code>sun.*</code>包，需要自己承擔風險。 欲了解更多詳細資訊，請參閱為什麼開發人員不應該編寫調用‘sun’包的程式。
對于deprecated api清單，請參閱deprecated api。
簡而言之，行為相容性意味着在輸入相同時，程式在不同版本的庫或平台執行相同（或等同）的操作。 有些平台行為的底層實作是故意設定為未定義的，這樣平台釋出可以更改。 出于這個原因，建議寫代碼不依賴于未定義的行為：如果依賴了未定義行為，問題不能算平台不相容，而是算代碼的bug。
java類檔案格式已經更新為java se 8版本。
按照jvm規範，java se 8的類檔案版本是52.0。 由java se 8編譯器産生的版本為52.0的類檔案不能在早期版本java se中使用。
下面的文檔有java語言規範（jls）和java虛拟機規範（jvms）的更改資訊。
jsr 337：java se 8釋出内容
盡管java se 8是與java平台的早期版本是非常相容的， 幾乎所有現有的程式可以不加修改地運作在java se 8，不過jre和jdk也有一些小的潛在的不相容性。為了完整性，這裡記錄極少數情況下“極端案例”。
本節介紹了java語言的jvm或java se api的java se 8不相容。
請注意，此版本中一些api已棄用，有些功能已被完全删除。 雖然這些都是不相容，他們被列為在單獨的清單。 欲了解更多資訊，請參閱deprecated apis和jdk 8移除的功能。
2015年3月java se 8進行了版本維護，不相容的問題有相應的修改。
~~jvm：接口預設方法不能觸發接口立即初始化
略
不相容性： 行為
bug：8043188~~(譯者注：8u40已修複)
~~jvm：jdwp支援接口預設方法和靜态方法
rfe：8042123~~(譯者注：8u40已修複)
jvm：對invokespecial指令調用執行個體初始化方法的校驗更加嚴格
（譯者注：隻有目前類型或直接超類的執行個體允許調用）
ref： 7160765 （譯者注：可能是安全相關，無法看到更詳細内容）
jvm：預設每個類檔案中都設定了acc_super标志
java se 8以及以上，java虛拟機預設每個類檔案中都設定了acc_super标志，無論标志在類檔案的實際值和類檔案的版本的。 該acc_super标志影響invokespecial的行為。
不相容性： 行為（譯者注：可能是安全相關，無法看到更詳細内容）
java：classes_text支援小語種
當使用dateformat和simpledateformat來格式化日期時間值時 ，上下文有關的月份名稱支援既有格式化形式又有獨立形式的小語種。 例如，在捷克語中，<code>一月</code>的格式化形式是<code>ledna</code>，而獨立形式是<code>leden</code>。 dateformatsymbols的getmonthnames方法和getshortmonthnames方法傳回這些語言的月份格式化形式。請注意，直到的java se 7，dateformatsymbols都是傳回獨立的形式。您可以用<code>calendar.getdisplayname</code>方法和<code>calendar.getdisplaynames</code>方法來制定傳回哪種形式。 請參考api文檔。
rfe：7079560
核心庫：javax.lang.model引入intersectiontype
在java se 8，對于具有multiple bounds的typevariables ，<code>javax.lang.model.type.typevariable.getupperbound</code>的傳回值和早期版本的傳回值不同。現在傳回新引入intersectiontype的執行個體，而原來傳回declaredtype的執行個體。 這可能會導緻<code>javax.lang.model.util.typevisitor</code>現有的實作行為改變：之前<code>typevariable.getupperbound</code>傳回multiple bounds變量時調用visitdeclared方法，現在調用visitintersection方法。 對傳回值調用getkind()也能觀察到差别。
rfe： 6557966
核心庫：non-public java.lang.reflect.proxy
實作了non-public interface的<code>java.lang.reflect.proxy</code>将是non-public, final, 且非abstract的。 在java se 8之前，代理類是public, final, 且非abstract。
如果現有的代碼不在同一個運作時package裡面調用<code>proxy.getproxyclass和constructor.newinstance</code>方法來建立一個代理執行個體，它會失敗，并抛illegalaccessexception。 對于這樣的代碼，它需要更改源碼為：（1）調用<code>constructor.setaccessible</code>設定通路标志設定為true，或（2）使用友善的<code>proxy.newproxyinstance</code>方法。
如果現有代碼試圖建立其他運作時package的non-public接口代理，需要授權新的permission <code>reflectpermission("newproxyinpackage.{package name}")</code>。
不相容性： 源碼
核心庫：java.lang.reflect.proxy不允許空invocationhandler
如果給定的invocationhandler參數為空，<code>java.lang.reflect.proxy(invocationhandler h)</code>構造函數現在抛nullpointerexception。
現有代碼使用空參數構造動态代理執行個體将抛nullpointerexception。 這種用法估計很罕見，因為空代理執行個體無論用在何處都将抛nullpointerexception。
rfe： 4487672
核心庫：java.math的bigdecimal.striptrailingzeros的零值問題
java se 8之前，如果調用<code>bigdecimal.striptrailingzeros</code>的數值等于零，将傳回該值。 現在則傳回常量<code>bigdecimal.zero</code>
不相容性質： 行為
rfe： 6480539
核心庫：java.net的httpurlconnection響應頭引号問題
在以前的版本中httpurlconnection摘要身份驗證實作有誤，在www-authenticate響應頭中對一些值加了引号。 在java se 8版本中，這些值不再加引号。 這是嚴格遵循<code>rfc 2617 http authentication: basic and digest access authentication</code>。
一些伺服器實作的某些版本已知預期這些值被引用。 http請求到這些伺服器可能無法再成功進行身份驗證。 而以前由于這些值被加引号而失敗的身份驗證，可能現在能成功驗證。
rfe： 8010505
核心庫：java.net的socket非臨時端口安全問題
在此版本中，配置設定給包括不可信代碼的所有代碼預設socket權限已被更改。 以前，所有代碼能夠bind任何類型的socket，以及任何大于或等于1024的端口号。此版本仍可以bind socket到每個系統上的臨時端口範圍。 臨時端口的确切範圍因作業系統而不同，但通常在高範圍（如從49152到65535）。新的限制是bind socket到臨時端口範圍之外需要顯式系統安全政策授權。絕大多數使用用戶端tcp socket（開啟了securitymanager）的應用将不會看到任何問題，因為這些通常bind到臨時端口。 而使用datagram socket或服務端tcp socket（開啟了securitymanager）應用可能抛安全異常。之前版本不會。 如果發生這種情況，使用者應該檢查被請求的端口号是否符合預期。如果符合預期，添加一個socket授權到本地安全政策來解決此問題。
核心庫：java.net的datagrampacket構造函數不再聲明異常
在java se 8之前，帶<code>java.net.socketaddress</code>參數的<code>java.net.datagrampacket</code>構造函數，聲明抛出<code>java.net.socketexception</code>。 然而，這個異常永遠不會被抛出。 在java se 8版本中，該構造函數不再聲明抛出java.net.socketexception。 如果的代碼catch了<code>socketexception</code>或它的超類<code>java.io.ioexception</code> ，在使用與java se 8編譯之前删除這些catch塊。
rfe： 8022126
核心庫：java.util.i18n的localeserviceprovider判斷locale問題
選擇<code>localeserviceprovider</code>的機制已經改變。<code>localeserviceprovider</code>的實作現在能夠通過overide<code>localeserviceprovider.issupportedlocale</code>方法來确定locale是否支援。 然而，如果從jdk7遷移locale service providers， overide此方法對于嚴格的擴充檢查可能涉及與現有應用程式的一些相容性問題。參考<code>localeserviceprovider</code>類及其<code>issupportedlocale</code>方法的描述了解更多細節。
rfe： 7168528
~~用戶端庫：java.awt
rfe： 7146237~~
安全庫：javax.net.ssl拒絕用戶端初始化的renegotiation
oracle jsse provider的新sytem property<code>jdk.tls.rejectclientinitializedrenego</code>拒絕用戶端初始化的renegotiation 。如果這個sytem property為true。服務端拒絕用戶端renegotiation的請求，并且抛出<code>handshake_failure</code>警報。
rfe： 7188658
hotspot jvm：gc删除perm
删除并忽略指令行選項 permsize和maxpermsize。 如果使用了這兩個選項，會發出如下警告：
rfe： 6965548
本段描述jdk 8在javac、hotspot或java se api中與jdk 7不相容之處。
需要注意的是，部分api在本次釋出中已經标注為不建議使用，甚至部分特性已經被完全移除。這些不相容的地方在這裡單獨列出來。如果需要更多的資訊，參看deprecated apis和jdk 8移除的功能。
~~jvm：jdi中接口支援預設方法和靜态方法
java se 8語言規範為接口引入了靜态方法和預設方法，是以jdi規範和具體實作中都已經允許使用這個技術。在jdi中，<code>com.sun.jdi.interfacetype</code>類包含了方法<code>value invokemethod(threadreference thread, method method, list<? extends value> arguments, int options)</code>。
rfe： 8042123~~(譯者注：8u40已修複)
~~核心庫：java.lang的windows中檢測登入使用者home目錄
在windows中檢測登入使用者home目錄的步驟，更新為遵照微軟推薦的方法。這處改動對在如下兩類情況下可能需要重點關注：1.比較舊的windows版本；2.使用者home目錄在系統資料庫或環境變量中設定到其他的目錄下。
rfe： 6519127~~
核心庫：java.lang.reflect的getmethods調用結果
新特性預設方法會影響兩個方法class.getmethod、class.getmethods的調用結果。
class.getmethod、class.getmethods的javadoc繼承了java語言規範的定義。java se 8改變了這個規則，以便支援預設方法的同時削減繼承于超接口的備援方法（可參考jls 8, 8.4.8）的數量。比如說，一個類有兩個超接口：i和j，每一個都定義了<code>int length();</code>，一般來說，我們認為兩個方法都是這個類的成員，但是如果j同樣擴充于i，那麼在java se 8中，這個類僅內建了一個方法：<code>j.length()</code>。
在java se 8釋出的時候，class.getmethod和class.getmethods的實作并沒有随定義的更新而更新（兩個方法都會傳回非繼承的超接口的方法）。從相容性看，這個差別沒那麼重要了，而與java se 7傳回的一緻性則是優先考慮的。是以無論如何，當重寫方法（如上面提到的<code>j.length</code>）為預設方法，首先應該要過濾掉其他重寫的方法（如上面提到的<code>i.length</code>）。
從jdk 8u20開始，代碼實作改為在重寫預設方法時，增加上面提到的過濾的步驟。
rfe： 8029674
核心庫：java.text舍入行為問題
在之前版本中，當使用<code>numberformat</code>和<code>decimalformat</code>類時，在特殊情況下是會發生舍入行為的錯誤。這種錯誤行為一般發生在調用<code>format()</code>方法時，給的值非常接近于格式化字元串所定義的中間位置。在這種情況下，錯誤的雙精度值舍入或不舍入行為就會發生。
舉例說，當使用預設推薦的<code>numberformatformat</code> api：<code>numberformat nf = java.text.numberformat.getinstance()</code>，跟着格式化代碼<code>nf.format(0.8055d)</code>，0.8055d值在計算機無法精确地表示為一個二進制的值，而是0.80549999999999999378275106209912337362766265869140625。在這裡預設的舍入是“half-even”法（譯者注：此舍入模式也稱為“銀行家舍入法”，主要在美國使用。四舍六入，五分兩種情況，如果前一位為奇數，則入位，否則舍去），jdk 7中調用<code>format()</code>方法會錯誤的輸出0.806，然而正确的值應該是0.805，因為記憶體中記錄的值是小于中間位置的。
在所有可能由程式員自定義樣式（而不是預設的樣式）的位置裡，這個舍入行為被修正。
rfe： 7131459
核心庫：java.util.collections的removeall，retainall不接受null
在之前的版本中，一些<code>collection.removeall(collection)</code>和<code>retainall(collection)</code>的實作會靜默的忽略傳入null參數的情況。從這個版本開始，如果集合傳入一個null參數，将會抛出一個<code>nullpointerexception</code>。
rfe： 8021591
核心服務：java.management強制管理接口public
在規範中提到的管理接口需要是puclic的，在這個版本中變成強制的了。非public的接口不存續暴露管理功能，所有的mbean和mxbean接口必須是public的。
系統屬性<code>jdk.jmx.mbeans.allownonpublic</code>用于恢複成之前允許非public管理接口的行為。這個屬性是過渡期使用的，在後續的釋出版中将會被移除。
在<code>java.awt.component.setfocustraversalkeys()</code>方法中，如果參數keystrokes裡的任何對象不是awtkeystroke的話，會抛出classcastexception（之前是illegalargumentexception）。
不相容性： 行為~~
安全庫：java.security限制com.sun.media.sound
<code>com.sun.media.sound</code>添加到了jdk 8受限制包清單中。在securitymanager下運作的應用無法通路這個包及其下各層級，除非得到明确的授權。<code>com.sun.media.sound</code>包一個内部的、不受支援的包，這相當于是說這不應該被外部的應用所使用。
rfe： 8019830
其他庫：corba限制se及其子包
jdk内部包com.sun.corba.se及其子包已被添加到受限包清單中，運作securitymanager情況下無法直接通路。
rfe： 8021257
工具：javac改正二進制比較的類型規則
java語言規範（jls）的15.21章節中關于二進制比較的類型規則沒有正确的被javac實施。從jdk 5 版本開始，javac根據jls規範15.21章節接受了一些類型不正确的對象-原生類型比較的程式。這些比較現在會被認為是類型錯誤。
rfe: 8013357
工具：javac參數和方法的注解拷貝到合成橋接方法
在這一次釋出中，參數和方法的注解将會拷貝到合成橋接方法。這個修複意味着現在程式類似：
每一個生成的橋接方法擁有所有的注解，參數注解也将會複制。這種行為上的改變将會影響一些注解處理器或任何使用注解的普通的程式。
rfe： 6695379
工具：javac參數注解會拷貝到自動生成的内部類構造器
參數注解會拷貝到自動生成的内部類構造器中。這個修複意味着現在如下的程式：
方法<code>m()</code>裡，内部類生成的構造器中，參數<code>int i</code>會有一個注解<code>@paramannotation</code>。這個行為的變化可能影響一些注解處理器，或者使用了注解的應用程式。
不相容性：
行為
工具：javac不再識别編譯目标值1.4.1、1.4.2和jsr14
javac不再識别編譯目标值<code>1.4.1</code>、<code>1.4.2</code>和<code>jsr14</code>，這些之前就沒有記錄在文檔中。很多最新的代碼生成慣用語中<code>1.4.1</code>、<code>1.4.2</code>比<code>1.4</code>使用的更多，而組合選項<code>-source 1.4 -target 1.5</code>會在更新一些的慣用語中使用，同時也會輸出更新一些的位元組碼檔案格式。“jsr14”選項則是泛型被添加到平台後的一個過度選項，現在泛型編譯目标應該是1.5或更高。
rfe： 8010179
工具：javac類型轉換編譯問題
下面的代碼在jdk 7中編譯會出現警告，而在jdk 8中将無法編譯：
jdk 8編譯上面的代碼中會報如下錯誤：
在這個例子中，原始類型被傳遞到<code>samplemethod(baz<object>)</code>方法中，而這個方法應該傳遞的是其子類型（參考jls，java se 7 edition, 15.12.2.2章節）。如果要可用的話，就需要一個未經檢查的轉換，而他的傳回類型是被擦除的（參考jls，java se 7 edition, 15.12.2.6章節）。在這個例子中，<code>samplemethod(baz<object>)</code>的傳回類型是<code>java.util.list</code>，而不是<code>java.util.list<baz<object>></code>，是以<code>get(int)</code>的傳回值是<code>object</code>，這就和被指派的baz類型不一緻了。
更多的資訊，請參見java.net上相關的電子郵件交流。
rfe： 7144506
工具：javac的final字段明确指派問題
~~使用<code>this</code>關鍵字為<code>final</code>字段明确的指派分析。
傳統的，java語言禁止通過簡單的名字（比如“x”）來通路沒有明确指派的final字段。在java se 7裡，字段是可以通過“this.x”進行通路的（參見： https://bugs.openjdk.java.net/browse/jdk-7004835）。任何合法的程式在舊的規則下是非法的，而在新的規則下是不安全的，因為他必然會通路一個沒有明确指派的空白的final字段。
從jdk 8u20開始，javac編譯器已經更新實作了java se 7的規則。
bug： 8039026~~（譯者注8u20已修複）
工具：javac接口的實作進行編譯時接口需要存在
當編譯一個類，這個類中使用到的其中一個類實作了一個接口，而這個接口定義在别的檔案中，這種類檔案（定義接口的檔案）在javac編譯時必須可用。這是jdk 8的一個新的需求，不這樣做會導緻一個編譯錯誤。例如：
client.java:
p1/a.java:
p1/i.java:
如果p1/i.java或p1/i.class在編譯client.java時不可用，就會出現下面的錯誤資訊：
xml：jaxp的xalan擴充功能安全問題
jaxp中的xalan擴充功能已經修改，以便于當securitymanager存在時，預設的實作總是會被使用。這一改變會影響dom document建立的nodeset。在之前，dom實作由dom工廠查找過程來定位。在這之後，當運作securitymanager時，查找過程會跳過，并且用預設的dom實作。
這個改變僅影響使用了第三方dom實作的應用。一般來說，nodeset結構預計與jdk預設實作相相容。
xml：jaxp1.6規範更新
jdk 8附帶了jaxp 1.6，包括規範更新，要求使用<code>java.util.serviceloader</code>查找服務提供者。跨jaxp的服務提供者能夠通過定義在<code>java.util.serviceloader</code>的流程被一緻的放置。而jdk7中提供者配置檔案可以是位于不同地方的，例如，通過不同的類加載器的<code>getxxx</code>方法比起<code>serviceloader</code>，這個改變導緻與jdk 7的細微的差異。
jdk 8 ships with jaxp 1.6 and so includes specification updates that mandate the use of java.util.serviceloader for finding service providers. service providers across jaxp will now be located consistently following the process as defined in java.util.serviceloader. the changes may result in some subtle differences from implementations of jdk 7 where the provider-configuration file may have been located differently, for example, by using a different getxxx method of the classloader than serviceloader.
應用實作自己的類加載器，應該确認類加載器的getxxx方式的實作是一緻的，以便保持相容性。
jsr 173中stax api定義了接收<code>factoryid</code>參數的<code>newinstance</code>和<code>newfactory</code>方法。因為在stax規範中對這個參數沒有任何限制，意味着可以是任意字元串。在jdk 8規範中進行了一下變更，在jaxp上下文裡，如果他想要表示服務配置檔案的名稱，factoryid的值必須是基本服務類的名字，即，他不是一個系統屬性名稱。
rfe： 8005954
xml：jaxp的javax.xml.stream工廠的類加載器不再忽略
在<code>javax.xml.stream</code>工廠中，類加載器參數不再能忽略。
<code>javax.xml.stream</code>包包含工廠類（xmleventfactory、xmloutputfactory、xmlinputfactory），這些工廠類定義newfactory方法時需要兩個參數：factoryid和classloader。在jdk 7中，第二個參數在查找和執行個體化服務時可以被省略。在jdk 8中不再能省略。可以參考這些方法的java api文檔來擷取更詳細資訊。
rfe：
8005954
api：java.lang的thread.stop關閉
<code>thread.stop</code>方法從jdk 1.2版本就被棄用了。這個方法現在會抛出一個unsupportedoperationexception。
核心庫：java.net從需要的協定處理程式的清單中移除ftp協定
ftp是一個曆史遺留的協定，它在很長時間内被一些更加安全的檔案傳輸協定（比如<code>sftp</code>）取代。<code>ftp</code>協定已經從協定處理程式清單中移除并且保證透明的。它實際上不是移除協定處理程式-應用使用這個協定時能夠繼續工作，但是它的存在已經不再需要。
rfe： 8000941
安全庫：java.security不支援不安全的1024以下rsr密鑰
在衡量基于加密算法的公鑰強度上，秘鑰的長度是一個很重要的安全參數。小于1024 bits的rsa秘鑰被認為是可以破解的。
在這次更新中，如果他們的rsa秘鑰長度小于1024 bits的話認證會被阻止。這個限制是通過java security property，<code>jdk.certpath.disabledalgorithms</code>實施。這種做法會影響附着security property的provider（比如sun provider和sunjsse provider）。security property和<code>jdk.certpath.disabledalgorithms</code>也同樣覆寫tls使用的靜态秘鑰（x.509證書秘鑰）的使用。
有了這些秘鑰長度的限制，這些使用基于長度小于1024 bits的rsa秘鑰的x.509證書在證書路徑的建立和驗證過程中會遇到相容性的問題。這些秘鑰的長度限制同樣會影響需要驗證x.509證書的jdk元件，比如jar簽名驗證，ssl/tls傳輸和https連接配接。
為了避免這些相容性問題，使用了基于長度小于1024 bits的rsa秘鑰的x.509證書的使用者會被推薦使用更強的秘鑰并更新他們的證書。作為一種變通的方法，在自己能夠承受的風險之上，為了允許較小長度的秘鑰，使用者可以調節秘鑰的長度來限制安全性（<code>jdk.certpath.disabledalgorithms</code>）。
~~install：安裝時不再提供關閉自動更新選項
為了關閉jre的自動更新，關閉自動更新并且設定部署配置中的系統屬性檔案的<code>deployment.expiration.check.enabled</code>屬性為<code>false</code>。為了關閉自動更新，移除java控制台中的更新按鈕中的檢測自動檢測功能。檢視deployment configuration file and properties擷取關于<code>deployment.expiration.check.enabled property</code>的更多資訊。~~
~~install：solaris的class data sharing檔案不會被建立
在這之前，solaris svid包在安裝時會建立class data sharing檔案。在jdk 8中，32位的solaris不再被支援，是以class data sharing檔案也預設不會被建立。如果想要手動建立class data sharing檔案。執行下列指令：
<code>$java_home/bin/java -xshare:dump</code>
當指令執行後，class data sharing檔案位于：
<code>$java_home/jre/lib/server/{amd64,sparcv9}/classes.jsa</code>。
rfe： 8023498~~
~~deployment：plugin移除經典的java plug-in
舊的java plug-in（java se 6u10之前的版本）會在這個版本中被移除。
rfe： 7076143~~
~~deployment：plugin移除java 快速開始（java quick starter）
java快速開始（jqs）服務在這個版本中會被移除
rfe： 8004321~~
~~deployment：plugin移除active-x bridge
active-x bridge在這個版本會被移除。
核心庫：sun.jdbc.odbc移除jdbc-odbc bridge
從jdk 8版本開始，jdk将不再包含jdbc-odbc bridge。jdbc-odbc bridge已經被認為是一個過渡期的産品，并且是一個僅僅用于選擇jdk軟體包并不包含在jre中的jre不支援的産品。可以使用資料庫供應商提供或者是一個商業版本的jdbc driver替換jdbc-odbc bridge。
rfe： 7176225
tools：apt移除apt工具
apt工具以及<code>com.sun.mirror</code>包中和它相關的api都将在這個版本中移除。使用指令行工具<code>javac</code>以及包<code>javax.annotation.processing</code>，包<code>javax.lang.model</code>處理注解。
7041249
~~tools：java移除32位的solaris
32位的solaris作業系統的java實作會在這個版本中移除。<code>$java_home/bin</code>和<code>$java_home/jre/bin</code>檔案夾現在隻包含64位的版本。為了過渡的目的，isa（instruction specific architecture）目錄中<code>$java_home/bin/{sparcv9,amd64}</code>和<code>$java_home/jre/{sparcv9,amd64}</code>有指向32位版本的符号連結。這些isa目錄将在jdk 9版本中被移除。
sunwj8rt，sunwj8dev和sunwj8dmo，這些之前包含32位版本的安裝包現在包含64位版本。sunwj8rtx，sunwj8dvx和sunwj8dmx安裝包将被移除。
64位版本的java不會包含諸如java web start和java plug-in的部署工具，是以桌面內建也不再需要了。
注意到64位的solaris的可執行檔案不能加載位32位solaris編譯和連結的jni庫。是以任何在32位solaris系統中建立的jni庫都需要重新編譯64位solaris版本。
rfe： 8023288~~
核心庫：java.lang:class_loading棄用endorsed
endorsed-standards override mechanism允許在java community process維護的标準之外，或者是持續獨立發展的作為java se平台的獨立的apis上實作新版本并且在運作時刻安裝。
一個子產品化的映像是由子產品而不是jar封包件組成。往前看，我們希望通過可更新的子產品（upgradeable module）隻支援子產品化形式的認可的标準和獨立的apis。
這個特性會在jdk 8u40版本中被棄用。這個棄用是為将來的java se版本中出現的module特性而做準備的。如果想要了解更多資訊，檢視jep 200 - the modular jdk和jep 220 - modular run-time images。
這些改變不會改變運作時刻的行為。
rfe： 8065675
核心庫：java.lang:class_loading棄用extension
擴充機制（extension mechanism）允許包含擴充了java se平台apis的jar檔案安裝到一個運作時映像，使它們的内容在可見的情況下編譯或運作的映像上的每一個應用程式。
這樣的擴充機制在釋出于1998年的jdk 1.2版本引入，但是在現在我們看不到任何憑證顯示有人去使用這個特性。這并不奇怪，因為多數現代的java應用程式會直接在class path上直接安裝類庫而不是在運作時刻去安裝類庫。
這個特性會在jdk 8u40版本時棄用。這個棄用是為将來的java se版本中出現的module特性而做準備的。如果想要了解更多資訊，檢視jep 200 - the modular jdk和jep 220 - modular run-time images。
這個特性的棄用需要下列标準規範的改變：
在<code>java.lang.system.getproperties()</code>方法中，<code>java.ext.dirs</code>系統屬性的規範會被修訂為包含一個會在将來版本中移除的棄用聲明。
在<code>java.util.jar.attributes.name</code>類中，域<code>extension_installation</code>，<code>implementation_url</code>和<code>implementation_vendor_id</code>的被棄用表明應該使用class path代替它們。
在jar檔案的規範中，所有和打包jar包的小程式依賴的已安裝的可選包和觸發對可選包下載下傳的相關的manifest屬性都被棄用。這些屬性包括：<code>xtension-name, extension-list, <extension>-extension-name, <extension>-specification-version, <extension>-implementation-vendor-id, <extension>-implementation-version, <extension>-implementation-url, implementation-vendor-id, implementation-url,</code>和<code>extension-installation</code>。
rfe： 8065702
核心庫：java.lang棄用securitymanager.checkmemberaccess
<code>securitymanager.checkmemberaccess</code>被棄用。它在調用者的棧幀深度為4的時候容易出錯。jdk的實作将不再調用<code>securitymanager.checkmemberaccess</code>方法去執行成員變量通路控制的檢測；替代它的是調用<code>securitymanager.checkpermission</code>方法。
通過重寫<code>checkmemberaccess</code>方法定制的<code>securitymanager</code>的實作可能會被影響導緻重寫的方法不會被調用。
核心庫：java.lang棄用securitymanager類的checktoplevelwindow, checksystemclipboardaccess, checkawteventqueueaccess
可替代的方法： <code>checkpermission</code>
rfe： 8008981
核心庫：java.rmi棄用rmi/jrmp的http代理
rmi/jrmp的http代理功能被棄用，而且http的代理功能預設被關閉
rfe： 8023862
核心庫：java.rmi棄用rmi(jrmp)靜态生成stubs
不再支援rmi(jrmp)靜态生成stubs
rfe： 8023863
核心庫：java.util.jar棄用pack200.unpacker接口的addpropertychangelistener和removepropertychangelistener
這些方法希望在将來的java se版本中移除
可替代的方法： 跟蹤unpacker執行過程，輪詢<code>progress</code>屬性的值。
rfe： 8000362
核心庫：java.util.logging棄用logmanager接口的addpropertychangelistener和removepropertychangelistener
核心庫：com.sun.security.auth.callback棄用dialogcallbackhandler類
使用時會告知将會被移除，在jdk 9的版本中會被徹底移除。
rfe： 7190273
核心服務：javax.management的rmi連接配接器iiop将移除
jsr-160規範已經更新了關于rmi連接配接器不再需要支援iiop傳輸。oracle jdk 8會繼續支援iiop的傳輸，但是支援iiop的傳輸希望會在将來版本的jmx remote api中移除。
rfe： 8001048
~~用戶端庫:javax.accessibility棄用javax.swing.jcomponent.accessiblefocushandler
可替代的方法： <code>java.awt.component.accessibleawtcomponent.accessibleawtfocushandler</code>
rfe： 7179482~~
~~javafx：scene graph棄用builder
可替代的方法： 使用合适的構造器和set方法去構造對象。
rfe： rt-30520~~
安全庫：java.security棄用insertprovider
<code>java.security.securitypermission insertprovider.{provider name}</code>的目标名稱在将來使用時會被勸阻，因為他可能在重寫<code>java.security.provider.getname</code>方法時會遇到命名限制而被阻止。同樣，在使用通過插入一個指定命名或者是選擇擷取的任意名稱的provider授予代碼權限時會有同樣的風險。
可替代的方法： 新的<code>insertprovider</code>目标名稱。相容現有已經被保留的policy檔案，原因在于新舊的權限都會被<code>security.addprovider</code>和<code>insertproviderat</code>方法檢測。
rfe： 8001319
hotspot jvm：gc棄用一些組合
以下的gc組合被棄用：
defnew + cms
parnew + serialold
incremental cms
對應的指令行選項會産生警告資訊并且建議你不要使用這樣的組合。這些指令行選項會在将來的某個主要版本中移除。
指令行選項<code>-xinggc</code>被棄用
指令行選項<code>-xx:cmsincrementalmode</code>被棄用。注意，這個指令行選項會影響所有的<code>cmsincremental</code>選項。
指令行選項<code>-xx:+useparnewgc</code>被棄用。除非你同時使用選項<code>-xx:+useconcmarksweepgc</code>。
指令行選項<code>-xx:-useparnewgc</code>隻有在和<code>-xx:+useconcmarksweepgc</code>選項一起使用時被棄用。
想要獲得更多的資訊，請檢視 http://openjdk.java.net/jeps/173
rfe：8006479
hotspot：gc棄用cms gc的前端收集器
cms gc的前端收集器（foreground collector）已經被棄用，并且希望在将來的某個版本中移除。使用g1或者是正常的cms替代。
比如在使用<code>-xx:+usecmscompactatfullcollection -xx:+cmsfullgcsbeforecompaction -xx:+usecmscollectionpassing</code>等選項時，會列印一個已經棄用的警告，但是vm仍會繼續工作。
rfe： 8027132
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)