仍然不安全:变成了Java 9功能的Java 6中的主要错误
sun.misc.Unsafe的未來將如何發展?
隨著2015年即將結束,我們認為這將是對Java社區過去一年中最熱門辯論之一進行尸檢的好機會。 通過查看標題,您中的大多數人可能已經開始在口腔中產生酸味并在腸道中產生憤怒的感覺,但是如果您錯過了該操作,讓我們來回顧一下所有引起大驚小怪的事情。
最重要的是:sun.misc.Unsafe不會走到任何地方
整個辯論始于7月,當時Oracle正在考慮刪除許多開發人員所依賴的作為JVM關鍵API之一的Unsafe庫。 該提案建議,在Java 9發行時,Unsafe將被完全封裝,盡管該Java版本的發行日程仍遙遙無期,但僅此宣布就在開發人員社區引起了軒然大波。
我們看到Reddit,Twitter和多個博客對此舉表示了批評,許多開發人員感到甲骨文“背叛了”,原因有以下三個主要原因:
暫時存在一個折衷方案,這是Java平臺組首席架構師Mark Reinhold建議的三步解決方案 。 該解決方案概述了封裝內部API(例如Unsafe)的所需過程:
所以現在的問題是:Oracle為什么要尋求消除不安全并從頭開始這場風暴? 要了解,我們可能應該在做出任何判斷之前以一種或另一種方式客觀地看待事物。
如何變得不安全
我們唯一可以啟動檢查此類火災原因的過程的地方就是Unsafe庫本身。 許多開發人員已經開始依靠其獨特的功能來完成各種任務,但是,請不要忘記,Unsafe庫實際上并不意味著內部開發團隊之外的任何人都可以訪問。 它曾經是而且仍然是一種不規則,巧合,各種錯誤。
當然,這是一次非常有用和快樂的巧合,但它根本就不會發生。 多年以來,各種不安全的用途已成為實際上的標準,但是這些用途中的任何一種的起源仍源于錯誤。 因此,期望Oracle無限期地保留過時的Sun *庫有點不合邏輯。畢竟,如果我們中有人發現了自己代碼中的錯誤,我們是否會努力消除它?
社區的反應–一場災難
隨著Unsafe風暴席卷整個Java開發人員社區,有兩個主要問題不斷出現。 第一個是先前討論的背叛感(是否合理,取決于您的觀點)。 第二個,也許稍微更合理-出于合理的擔心,封裝Unsafe將有史以來第一次違反Java的一項主要承諾-向后兼容性。
一些開發人員一直在發布有關消除或限制訪問Unsafe的可能結果的世界末日帖子,稱許多工具,庫和基礎結構軟件直接或在可見代碼下方使用該庫,其中包括Hazelcast,Cassandra,Spring等。其他。
如果要完全實現Oracle的封裝計劃,那么使用一個或多個這些工具的任何開發人員都會遇到嚴重的困難。
甲骨文的立場–
該庫的名稱應表明該庫存在使用風險,并且Oracle所做的一切實際上都是在試圖最大程度地降低任何潛在風險。 在任何地方使用標題為“不安全”的庫有點像看到雷區,成功穿越它,然后邀請所有朋友也穿越它,因為它“為您工作”。 那只會導致一個結果:
多年來,Oracle一直在解釋說,盡管他們贊賞所有社區使用Unsafe庫在開發方面所做的努力,但是訪問這樣低級的庫應該被視為有使用風險。 不負責任地使用未記錄的庫可能會在使用該庫的任何平臺上導致各種內存問題和其他處理過載。 就Oracle而言,這就是“不太理想的結果”的確切定義。 可能需要注意的是,并不是所有Java中的“棄用”在發生時都被認為是不好的,有些人,例如刪除PermGen最終被稱贊為“ 非常積極” 。
最后的想法
看起來,盡管Java平臺團隊看到了抗議的蔓延(他們很可能知道抗議即將來臨)并最終找到了解決該問題的合理解決方案,或者至少可以與開發人員社區一起生活。
距離Java 9的實際發布版本還有1年多的時間,無論是否以任何形式或形式存在Unsafe庫,而且其他更改和聲明可能很快就會到來。 您可以訪問我們的倒計時站點java9countdown.xyz并注冊新聞通訊,以獲取有關Java 9所有相關問題的最新信息。
翻譯自: https://www.javacodegeeks.com/2016/01/still-unsafe-major-bug-java-6-turned-java-9-feature.html
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的仍然不安全:变成了Java 9功能的Java 6中的主要错误的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 湖北本科大学排名一览表(湖北高校排名更新
- 下一篇: java 7.函数-递归_带有谓词的Ja