会计公司网站模板,服务器搭建云手机,深圳市建设局工程交易中心网站,百度站长工具收费吗灾难将至#xff0c;Java 9中将移除 Sun.misc.UnsafeOracle 正在计划在Java 9中去掉 sun.misc.Unsafe API。 这绝对将是一场灾难#xff0c;有可能会彻底破坏整个 java 生态圈。 几乎每个使用 java开发的工具、软件基础设施、高性能开发库都在底层使用了 sun.misc.Unsafe。 下…灾难将至Java 9中将移除 Sun.misc.UnsafeOracle 正在计划在Java 9中去掉 sun.misc.Unsafe API。 这绝对将是一场灾难有可能会彻底破坏整个 java 生态圈。 几乎每个使用 java开发的工具、软件基础设施、高性能开发库都在底层使用了 sun.misc.Unsafe。 下面是上面链接中文档提到一个小列表NettyHazelcastCassandraMockito / EasyMock / JMock / PowerMockScala SpecsSpockRobolectricGrailsNeo4jSpring FrameworkAkkaApache KafkaApache WinkApache StormApache HadoopApache 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 为代价。 人们在开发新软件的时候就会逐步过渡到新的 APIUnsafe 就自动被废弃了。这类似于向 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之前的版本 – 使用 UnsafeJava 9兼容 – 不使用 Unsafe。迁移至 Java 9的进程会因此而变缓慢这将影响整个 Java 生态系统。这将会类似于 Python 2升级到 Python 3的过程。这种错误 JVM 社区之前曾经犯过你是不是任务这太荒唐了Oracle 绝不可能犯这样的错误事实上它曾做过类似的事情了 例如Java 7中的字节码校验器。结论现在是该让大家开始意识到这个问题的时候了。从 JVM中去掉Unsafe或者把它隐藏在某个特殊的 flag 里面势必导致一场灾难。参考链接
