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,
@BetaAPIs 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
@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).
This could be the concern you brought up when talking about "braking up in the future", but...
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.
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@Betaonly 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).