Java 9中將移除 Sun.misc.Unsafe
災難將至，Java 9中將移除 Sun.misc.Unsafe
Oracle 正在計劃在Java 9中去掉 sun.misc.Unsafe API。 這絕對將是一場災難，有可能會徹底破壞整個 java 生態圈。 幾乎每個使用 java開發的工具、軟體基礎設施、高效能開發庫都在底層使用了 sun.misc.Unsafe。 下面是上面連結中文件提到一個小列表：
- Netty
- Hazelcast
- Cassandra
- Mockito / EasyMock / JMock / PowerMock
- Scala Specs
- Spock
- Robolectric
- Grails
- Neo4j
- Spring Framework
- Akka
- Apache Kafka
- Apache Wink
- Apache Storm
- Apache Hadoop
- Apache Continuum
… 這個列表很長。。。
然而， Oracle 看起來是鐵了心毫無理由的去掉它。下面是一個來自他們郵件列表的評論： n
恕我直言 —
sun.misc.Unsafe必須死掉。 它是“不安全”的。它必須被廢棄。請忽略一切理論上(想象中的)羈絆，從此走上正確的道路吧。
這個工程師似乎是毫無根據的憎恨 Unsafe。。。
Oracle應該怎麼做？
當前Unsafe 類是一個強有力的工具。 沒有必要去掉它。對這個類的特性有些明確的需求，這就是為什麼事實上幾乎每個 Java 程式都在使用它，不知不覺中許多流行的 Java庫也在使用它。
提供完整的文件、釋出 Unsafe 類
Oracle 應該接受現實，並將Unsafe轉為公開 API，提供完善的文件和開發示例。 當前，沒有準確的文件，開發中需要通過 stackoverflow 帖子或者其他一些隨機的部落格學習怎麼使用 Unsafe。 移除 Unsafe 的一個主要論據是：使用它太容易讓開發中犯錯了。如果有完善的官方文件或許可以改善這一現狀。
隨 Unsafe一起釋出新的替代 API
除了 Unsafe 文件外，Oracle 應該釋出一個更易用的 API，提供 Unsafe 相同的功能。 這是上面文件中的提議的一部分。然而這不太應該以移除 Unsafe 為代價。 人們在開發新軟體的時候就會逐步過渡到新的 API，Unsafe
這類似於向 Java 8引入 java.time 包中的新的 DateTime API。 新的日期 API 的引入並不表示之前的DateTime API 被徹底移除或者隱藏到某個特殊 JVM flag 裡。那樣也肯定會引發一些事故。
實際上最可能會變成什麼樣子？
根據事情的發展趨勢，Oracle 看起來會：
- 在 Java 9正常模式下移除
Unsafe類。- 僅在必須的情況下通過向 JVM 傳遞一個特殊的 flag 啟動
Unsafe
這將導致絕對的災難！
- 不僅類似 Cassandra 或Zookeeper 等基礎軟體，幾乎所有的 Java 程式，包括 web 應用也會掛掉，因為他們使用的基礎庫可能在底層使用了
Unsafe。 - 從此開啟 Unsafe flag 將會成為啟動 JVM 的預設 flag 之一，因為如果不開啟它的話 Java 應用會在毫無提示的情況下崩潰。
- 因為大多數環境不會預設把這個JVM flag 開啟，當他們的系統升級 Java時軟體系統會掛掉。 Java 打破了向後相容的承諾。所有的基礎庫、軟體基礎設施從此變為兩個版本：
- Java 9之前的版本 – 使用
Unsafe - Java 9相容 – 不使用
Unsafe。
- Java 9之前的版本 – 使用
- 遷移至 Java 9的程序會因此而變緩慢，這將影響整個 Java 生態系統。這將會類似於 Python 2升級到 Python 3的過程。
這種錯誤 JVM 社群之前曾經犯過
你是不是任務這太荒唐了，Oracle 絕不可能犯這樣的錯誤？事實上它曾做過類似的事情了， 例如Java 7中的位元組碼校驗器。
結論
現在是該讓大家開始意識到這個問題的時候了。從 JVM中去掉Unsafe或者把它隱藏在某個特殊的 flag 裡面勢必導致一場災難。
參考連結
