On a general note (I don't know the exact details of the issue) of API design, I would also be very wary of returning an exact collection type, as it prevents implementation optimisation.
If you aren't wanting to allow use of foreach style statements, then I can't see much use in upgrading to Iterator/Iterable.
On 10 Jan 2012, at 12:37, Nigel Deakin wrote:
> 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> 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> 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> 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
>>>>>>
>>>>
>>>
>>
>>