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 看起來會：

1. 在 Java 9正常模式下移除 Unsafe 類。
2. 僅在必須的情況下通過向 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 生態系統。這將會類似於 Python 2升級到 Python 3的過程。

這種錯誤 JVM 社區之前曾經犯過

你是不是任務這太荒唐了，Oracle 絕不可能犯這樣的錯誤？事實上它曾做過類似的事情了， 例如Java 7中的字節碼校驗器。

結論

現在是該讓大家開始意識到這個問題的時候了。從 JVM中去掉Unsafe或者把它隱藏在某個特殊的 flag 裡面勢必導致一場災難。