The RFE is to add a separate method to ReferenceQueue that takes no
arguments, declares no checked exceptions thrown, returns a Reference, and
is functionally equivalent to the current remove(ReferenceQueue.POLL).
It could be called "poll", "removePoll", "pollRemove", or something similar.

Currently, ReferenceQueue has two methods for removing the reference object at
the head of the queue:

Reference remove(long timeout) throws InterruptedException
Reference remove() throws InteruptedException

The no-arg version is equivalent to remove(0), consistent with the "wait"
methods in Object, i.e. it blocks indefinitely until there is a Reference that
can be removed from the queue.

There is also the variation of calling remove(ReferenceQueue.POLL) (a constant
of -1) that never blocks; it either returns a Refernece or null, if none was on
the queue. This is very useful with some applications of reference queues, but
supporting this feature with the same method that can block in other cases
results in awkward application code, because InterruptedException still must be
caught, even though it cannot happen in the POLL case, so it confuses the look
of an algorithm that should not, logically, have to worry about catching
InterruptedException at that stage (although the contents of the catch block are
irrelevant).

Following is a e-mail exchange with mr@eng about this issue:

From Mark.Reinhold@Eng Thu Dec 4 20:08:41 1997
To: ###@###.### (Peter Jones - JavaSoft East )
cc: ###@###.###
Subject: Re: (late) ref queue poll comment
From: Mark Reinhold <Mark.Reinhold@Eng>
 
[ Wading through old e-mail -- here's an equally late reply ]
 
> Date: Mon, 10 Nov 1997 13:44:53 -0500
> From: ###@###.### (Peter Jones - JavaSoft East )
 
> I know that it's rather late for comments, but I hadn't tried using
> ReferenceQueues in other than a blocking-thread-for-queue situation
> until now... The API would be a bit more convenient if there was a
> separate method to poll the queue instead of having to invoke
> queue.remove(ReferenceQueue.POLL), because the requirement to catch
> InterruptedException doesn't really make sense in the poll situation.
> It can't happen (right?), so the caller just needs to have a dummy
> catch block whenever a poll is required. A separate method would also
> be a bit cleaner than using a magic value, but it was unnecessary
> requirement for exception catching that compelled me to bring this up.
 
You're right -- if you pass POLL to remove you'll never get an
InterruptedException. If you file an RFE I'll see about adding a public poll
method for beta3.