I can't see any merit in returning a Set. What would we expect applications to use it for, other than call the
iterator() method? (Though given that a Set is unordered, would an application really want to be able to fetch messages
from a queue in a random order?)
Aside from the major issue of memory usage and performance, methods like contains() couldn't be used portably since the
JMS spec doesn't define how equals() behaves. (If applications really want to search through the queue for specific
messages they can supply a message selector when they create the queue browser).
I agree that Enumeration has been superseded by Iterator, but Enumeration is definitely not deprecated and the
difference is small. I might argue that since Iterator defines a remove() method which we would not support then this
might actually be confusing.
But perhaps we should as part of a more general review we might have of the browsing and monitoring features of JMS
rather than on its own. For example, do we need to allow durable subscriptions to be browsed? Do we need to add
additional methods to allow the state of the queues and topics to be queried? This is something we might want to
revisit after the Early Draft.
Nigel
On 09/01/2012 22:31, John D. Ament wrote:
> Rudiger
>
> The ideal case would be the foreach styled loop.
>
> John
>
> On Mon, Jan 9, 2012 at 3:26 PM, Rüdiger zu Dohna <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.de>> wrote:
>
> @John: You can't do much with that Set than iterate over it, can you? Maybe even calculating the size could be
> expensive.
> @Nigel: Enumerations are just somewhat old fashioned and more ore less deprecated. If it was an Iterable
> (contradicting myself), you could use it for an enhanced for-loop.
>
>
> On 2012-01-09, at 19:45, John D. Ament wrote:
>> I don't see much of a reason to not use a Set, since it should be unique. It could be a custom implementation
>> that buffers the messages from the server.
>>
>> Just feels more modern to work with a clean collection rather than an enumeration.
>>
>> John
>>
>> On Mon, Jan 9, 2012 at 1:39 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>>
>> Given that a QueueBrowser already provides a method to return an Enumeration, what would be the benefit in
>> additionally returning a Iterator (unless we wanted to add support for remove())?
>>
>> Nigel
>>
>>
>> On 09/01/2012 16:32, Rüdiger zu Dohna wrote:
>>> Maybe it should return an Iterator<Message>? ... deliberately not an Iterable! This would make it clear that
>>> it's just a snapshot and there's no much use to pass it as a collection around.
>>>
>>>
>>> On 2012-01-09, at 15:01, Nigel Deakin wrote:
>>>
>>>> John,
>>>>
>>>> Simply returning a Set isn't very scalable: a queue might contain thousands (or hundreds of thousands) of
>>>> messages. That's why the existing API returns an Enumeration.
>>>>
>>>> (Also, since a Queue is by definition ordered, returning a Set would be throwing away important semantics)
>>>>
>>>> Nigel
>>>>
>>>> On 09/01/2012 13:40, John D. Ament wrote:
>>>>> Hi Nigel,
>>>>>
>>>>> No, I would leave the existing method, and add a new one:
>>>>>
>>>>> public Set<Message> getMessages() throws JMSRuntimeException { }
>>>>>
>>>>> I think Set is most appropriate, since the messages should be unique.
>>>>>
>>>>> On Mon, Jan 9, 2012 at 7:06 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>>>>>
>>>>> John,
>>>>>
>>>>>
>>>>> On 06/01/2012 10:49, John D. Ament wrote:
>>>>>
>>>>> It may be a bit late, but is it possible for us to provide a set or list back that is properly
>>>>> typed (e.g.
>>>>> javax.jms.Message) from QueueBrowser?
>>>>>
>>>>>
>>>>> Can you be more specific about what you are asking for?
>>>>>
>>>>> Are you asking for the existing method
>>>>> Enumeration getEnumeration() throws JMSException;
>>>>> to be changed to
>>>>> Enumeration <Message> getEnumeration() throws JMSException;
>>>>>
>>>>> or something else?
>>>>>
>>>>> Nigel
>>>>>
>>>>>
>>>
>>
>
>