Guava 的 EvictingQueue 的替代品，用 @Beta 注释 [英] Alternatives to Guava's EvictingQueue, which is annotated with @Beta

问题描述

在我项目的一个关键部分，它基本上允许控制器异步接收对象，放入Queue，由一个线程一次从队列中顺序处理，然后服务响应, 较旧的处理对象保留在队列中，直到插入新项目.

回到过去(几个月前)，我的 Queue 实现是使用 Guava 的 EvictingQueue，现在标记为 @Beta，因此这部分应用程序可能会在未来的 Guava 版本中中断.

私有最终队列items = Queues.synchronizedQueue(EvictingQueue.create(queueSize));

是否有任何线程安全和固定大小替代EvictingQueue来实现这个目标?

解决方案

您的帖子中有几个不准确/错误，所以让我们试着找到共同点.

首先，Guava 中的任何新功能从一开始就被注释为 @Beta，对于 15.0 中的EvictingQueue(此链接到 15.0 文档).所以几个月前你可能错过了这个事实，但没关系，因为...

...@Beta 并不意味着它会在没有任何通知的情况下进行更改——相反，前段时间，经过社区的一些反馈，Guava 开发人员建立了相当严格的标准关于什么和什么时候可以改变的政策.请参阅 PhilosophyExplained wiki 页面，其中说(重点是我的):><块引用>

测试版 API

Beta API 代表我们不准备因任何原因冻结的 Guava 功能:因为这些方法可能找不到足够的用户，因为它们可能被移动，因为它们的用途可能太窄而无法将它们包含在 Guava 中.

>

也就是说，@Beta API 已经过全面测试和支持，并且得到了 Guava 其余部分所给予的所有关心和喜爱.

这意味着 EvictingQueue 的质量并不比它不是测试版功能"时差.

<块引用>

@Beta 注释最大的内涵是被注释的类或方法是可以改变的.它们可以以任何方式修改，甚至可以随时删除.如果您的代码本身是一个库(即它在您自己控制之外的用户的 CLASSPATH 上使用)，则不应使用测试版 API，除非您重新打包(例如使用 ProGuard).

这可能是您在谈论未来刹车"时提出的担忧，但是...

<块引用>

综上所述，@Beta 功能往往保持相对稳定.如果我们决定删除一个 @Beta 功能，我们通常会在删除它之前在一个版本中弃用它.

所以它不会无声无息地发生(据我观察，通常有不止一个版本被弃用).

最后一点:

<块引用>

另一方面，如果您想从 @Beta 中删除某些内容，请提交问题.我们通常会从 @Beta 中推广功能> 只在特别要求的时候，所以如果你不问，它就不会发生.

总结:我建议你提交一张票来推广EvictingQueue，并使它成为非@Beta，这样可以消除任何疑虑.另一方面，EvictingQueue 的实现非常简单和独立，所以如果它被删除(不太可能)你可以重新打包它(即使用 ProGuard)甚至将代码复制到你的项目中(所有许可证).

In a critical part of my project which basically allows objects to be received by a controller asynchronously, put into a Queue, processed sequentially from the queue one at a time by a thread, then service responds, older processed objects are kept in the queue until newer item insertion.

Back in time (months ago), my Queue implementation for solving this particular business specific issue behind this was to use Guava's EvictingQueue, which now is marked as @Beta, and so this part of the application can break in future Guava releases.

private final Queue<SomeRandomBusinessObject> items = Queues.synchronizedQueue(EvictingQueue.create(queueSize));

Are there any thread-safe and fixed-size alternatives to EvictingQueue to achieve this goal?

解决方案

There are couple of inaccuracies / mistakes in your post, so let's just try to find common ground.

First, any new feature in Guava is annotated as @Beta from the beginning, same is true for EvictingQueue in 15.0 (this links to 15.0 docs). So you probably missed that fact couple months ago, but that's OK, because...

...@Beta doesn't really mean it'll be changed without any notice -- on the contrary, some time ago, after some feedback from the community, Guava devs established pretty strict policy about what and when can be changed. See PhilosophyExplained wiki page, which says (emphasis mine):

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.

This means EvictingQueue quality is not worse than if it wasn't a "beta feature".

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).

This could be the concern you brought up when talking about "braking up in the future", but...

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.

So it won't happen silently (as far as I observed, usually there's more than one release with deprecating though).

Which brings me the the last point:

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.

To sum up: I'd suggest you to file a ticket to promote EvictingQueue and make it non-@Beta, which would remove any doubts about it. On the other hand, the EvictingQueue's implementation is quite simple and standalone, so if it's removed (unlikely) you can repakckage it (i.e. use ProGuard) or even copy the code to your project (with all the licenses).

这篇关于Guava 的 EvictingQueue 的替代品，用 @Beta 注释的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！