你的文章中有几个不准确/错误，所以让我们试着找到共同点。
首先，Guava中的任何新特性都被注解为 @Beta 从一开始，同样的道理也适用于 EvictingQueue 在15.0中（链接到15.0文档）。所以你可能错过了几个月前的事实，但没关系，因为。。。
... @Beta 这并不意味着它会在没有任何通知的情况下被更改——相反，不久前，在社区的一些反馈之后，guava devs制定了非常严格的政策，关于什么时候可以更改。参见哲学解释维基页面，上面写着（我的重点）：

贝塔API

beta-api代表了guava的特性，不管出于什么原因，我们都没有准备好冻结这些特性：因为这些方法可能找不到足够的用户，因为它们可能会被移动，因为它们的使用范围可能太窄，无法将它们包含在guava中。
也就是说， @Beta 原料药得到了充分的测试和支持，并得到了其他Guava所得到的所有关怀和关爱。
这意味着 EvictingQueue 质量并不比不是“beta特性”差。
最大的内涵 @Beta 注解是指被注解的类或方法可能会发生更改。它们可以以任何方式修改，甚至可以随时删除。如果您的代码本身是一个库（即，它在您自己控制之外的用户的类路径上使用），则不应使用beta api，除非您重新打包它们（例如，使用proguard）。
这可能是你在谈到“未来刹车”时提到的问题，但是。。。
所有这些都说， @Beta 特征往往保持相对稳定。如果我们决定删除 @Beta 特性，我们通常会在删除它之前将其弃用一个版本。
所以它不会悄无声息地发生（据我观察，通常有不止一个版本带有贬损）。
最后一点是：
另一方面，如果你想从 @Beta ，提交问题。我们通常会在 @Beta 只有在特别要求的时候，所以如果你不问，就不会发生。
总而言之：我建议你申请一张宣传票 EvictingQueue 让它成为非- @Beta ，这将消除任何疑虑。另一方面 EvictingQueue 的实现是非常简单和独立的，因此如果它被删除（不太可能），您可以将其重新打包（即使用proguard），甚至可以将代码复制到您的项目中（使用所有许可证）。