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.
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.
- duplicates
-
JDK-4102620 java.lang.ref.ReferenceQueue should have separate poll() method
- Closed