Guava 的 EvictingQueue 的替代品，用 @Beta 注释
Alternatives to Guava's EvictingQueue, which is annotated with @Beta
在我的项目的一个关键部分，它基本上允许控制器异步接收对象，将对象放入 Queue，线程从队列中依次处理一个对象，然后服务响应，较旧的已处理对象将保留在队列中，直到插入新的项目。
回到过去（几个月前），我的 Queue 解决此特定业务特定问题的实现是使用 Guava 的 EvictingQueue，现在标记为 @Beta，因此应用程序的这一部分可能会在未来的 Guava 版本中中断。
private final Queue<SomeRandomBusinessObject> items = Queues.synchronizedQueue(EvictingQueue.create(queueSize));
是否有线程安全和固定大小替代EvictingQueue来实现这个目标？
您的 post 中存在一些不准确/错误，所以让我们尝试找到共同点。
首先，Guava 中的任何新功能从一开始就被注释为 @Beta，EvictingQueue in 15.0 也是如此（这链接到 15.0 文档）。所以几个月前你可能错过了这个事实，但这没关系，因为...
...@Beta 并不意味着它会在没有任何通知的情况下进行更改——相反，前段时间，在社区的一些反馈之后，Guava 开发人员制定了非常严格的政策什么时候可以改变。见 PhilosophyExplained wiki page，它说（强调我的）：
Beta APIs
Beta APIs represent Guava features that we aren't ready to freeze for whatever reason: because the methods might not find enough users, because they might be moved, because their uses might be too narrow to include them in Guava.
That said, @Beta APIs are fully tested and supported, and treated with all the care and affection that the rest of Guava receives.
这意味着 EvictingQueue 质量并不比它不是“测试版功能”时差。
The biggest connotation of the @Beta annotation is that annotated classes or methods are subject to change. They can be modified in any way, or even removed, at any time. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard).
这可能是您在谈到“将来分手”时提出的担忧，但是...
All this said, @Beta features tend to remain relatively stable. If we decide to delete a @Beta feature, we will typically deprecate it for one release before deleting it.
所以它不会悄无声息地发生（据我观察，通常会有不止一个版本被弃用）。
最后一点：
On the other hand, if you want something taken out of @Beta, file an issue. We generally promote features out of @Beta only when it's specifically requested, so if you don't ask, it won't happen.
总结一下：我建议您提交一张票来宣传 EvictingQueue 并使其成为非 @Beta，这将消除对此的任何疑虑。另一方面，EvictingQueue 的实现非常简单且独立，因此如果它被删除（不太可能），您可以重新打包它（即使用 ProGuard），甚至将代码复制到您的项目（使用所有许可证） .
在我的项目的一个关键部分，它基本上允许控制器异步接收对象，将对象放入 Queue，线程从队列中依次处理一个对象，然后服务响应，较旧的已处理对象将保留在队列中，直到插入新的项目。
回到过去（几个月前），我的 Queue 解决此特定业务特定问题的实现是使用 Guava 的 EvictingQueue，现在标记为 @Beta，因此应用程序的这一部分可能会在未来的 Guava 版本中中断。
private final Queue<SomeRandomBusinessObject> items = Queues.synchronizedQueue(EvictingQueue.create(queueSize));
是否有线程安全和固定大小替代EvictingQueue来实现这个目标？
您的 post 中存在一些不准确/错误，所以让我们尝试找到共同点。
首先，Guava 中的任何新功能从一开始就被注释为 @Beta，EvictingQueue in 15.0 也是如此（这链接到 15.0 文档）。所以几个月前你可能错过了这个事实，但这没关系，因为...
...@Beta 并不意味着它会在没有任何通知的情况下进行更改——相反，前段时间，在社区的一些反馈之后，Guava 开发人员制定了非常严格的政策什么时候可以改变。见 PhilosophyExplained wiki page，它说（强调我的）：
Beta APIs
Beta APIs represent Guava features that we aren't ready to freeze for whatever reason: because the methods might not find enough users, because they might be moved, because their uses might be too narrow to include them in Guava.
That said,
@BetaAPIs are fully tested and supported, and treated with all the care and affection that the rest of Guava receives.
这意味着 EvictingQueue 质量并不比它不是“测试版功能”时差。
The biggest connotation of the
@Betaannotation is that annotated classes or methods are subject to change. They can be modified in any way, or even removed, at any time. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard).
这可能是您在谈到“将来分手”时提出的担忧，但是...
All this said,
@Betafeatures tend to remain relatively stable. If we decide to delete a@Betafeature, we will typically deprecate it for one release before deleting it.
所以它不会悄无声息地发生（据我观察，通常会有不止一个版本被弃用）。
最后一点：
On the other hand, if you want something taken out of
@Beta, file an issue. We generally promote features out of@Betaonly when it's specifically requested, so if you don't ask, it won't happen.
总结一下：我建议您提交一张票来宣传 EvictingQueue 并使其成为非 @Beta，这将消除对此的任何疑虑。另一方面，EvictingQueue 的实现非常简单且独立，因此如果它被删除（不太可能），您可以重新打包它（即使用 ProGuard），甚至将代码复制到您的项目（使用所有许可证） .