On 19/09/2011 09:08, Ruediger zu Dohna wrote:
> +1
>
> There are a lot of "+1" mails being sent.
Sounds as if we are making progress!
> It we'd just send them to you and not to the mailing list, you'd have to
> collect and publish the names after "the poll" so everything stays transparent. Maybe it would be better to track that
> on JIRA: Allow only members of the EG to vote for issues; objections can be made by comment (which is a good practice
> anyway).
I'd prefer to keep things informal. So long as people make sure they "vote" on the correct thread, I find the current
mechanism easy enough to manage.
Nigel
>
> On 16.09.2011 17:25, Nigel Deakin wrote:
>> On 15/08/2011 16:12, Nigel Deakin wrote:
>>> I have logged the following issue:
>>> http://java.net/jira/browse/JMS_SPEC-47
>>>
>>> This issue was were raised by Adrian and Shivajee, who proposed
>>> "Removal of Queue and Topic specific interfaces in favor
>>> of general ones "
>>>
>>> This is another long description and it may be easier to read the
>>> formatted version in the JIRA issue rather than the
>>> text version below. In any case, I would appreciate your comments on
>>> this proposal to deprecate over one third of the
>>> JMS API!
>>
>> I've received two votes of approval for this, and no objections or
>> comments. Remember, there are two aspects to this:
>>
>> * These interfaces would be formally marked as deprecated, by use of the
>> @java.lang.Deprecated annotation. This would cause compilers to issue a
>> warning when a deprecated method was used.
>>
>> * These interfaces would be formally marked in the specification as
>> being "proposed for removal", with the expectation that they would be
>> made optional in the next release.
>>
>> Since this is quite a major change, I'd like to invite explicit approval
>> or disapproval (or just comments).
>>
>> (This is dependent on a small change to make
>> Session.createDurableSubscriber() return a MessageConsumer instead of a
>> TopicSubscriber as at present. I've moved this to a separate issue,
>> JMS_SPEC-51).
>>
>> Nigel
>>
>>
>>> Nigel
>>>
>>> Summary
>>> -------
>>>
>>> In version 1.0b of the JMS specification, applications had to use a
>>> completely separate set of interfaces when working
>>> with queues as they did when working with topics.
>>>
>>> Specifically, applications working with queues had to use the
>>> interfaces QueueConnectionFactory, QueueConnection,
>>> QueueSession, QueueSender and QueueReceiver, whilst applications
>>> working with topics had to use the interfaces
>>> TopicConnectionFactory, TopicConnection, TopicSession, TopicPublisher
>>> and TopicSubscriber.
>>>
>>> Although these two sets of interfaces shared common supertype
>>> interfaces ConnectionFactory, Connection, Session,
>>> MessageProducer and MessageConsumer, these were effectively abstract
>>> classes, and applications were forced to use the
>>> interfaces specific for the messaging domain (queue or topic) that
>>> they were using.
>>>
>>> In version 1.1, new API methods were added to the common superclass,
>>> domain-independent, interfaces to allow them to be
>>> used directly by client applications. This offered a simpler
>>> programming model, and for first time allowed queues and
>>> topics to participate in the same local transaction, now that they
>>> could be accessed using the same session.
>>>
>>> In JMS 1.1 all of the domain-specific interfaces were retained to
>>> provide backwards compatibility, but it was stated in
>>> Section 1.5 that "in the future, some of the domain-specific APIs may
>>> be deprecated".
>>>
>>> For 2.0 it is time to take this to the next stage, and to formally
>>> announce that these interfaces are now deprecated and
>>> that they will be removed from a future version of the specification.
>>>
>>> This would remove 15 interfaces from JMS and reduce the total number
>>> of interfaces by 34%, from 44 to 28.
>>>
>>> Detail
>>> -----
>>>
>>> This change would affect the following interfaces:
>>>
>>> XAQueueConnection
>>> XAQueueConnectionFactory
>>> XAQueueSession
>>> XATopicConnection
>>> XATopicConnectionFactory
>>> XATopicSession
>>> QueueConnection
>>> QueueConnectionFactory
>>> QueueReceiver
>>> QueueSender
>>> QueueSession
>>> TopicConnection
>>> TopicConnectionFactory
>>> TopicPublisher
>>> TopicSession
>>> TopicSubscriber
>>>
>>> There would be two changes:
>>>
>>> * These interfaces would be formally marked as deprecated, by use of
>>> the @java.lang.Deprecated annotation. This would
>>> cause compilers to issue a warning when a deprecated method was used.
>>>
>>> * These interfaces would be formally marked in the specification as
>>> being "proposed for removal", with the expectation
>>> that they would be made optional in the next release.
>>>
>>> There do not appear to be any binding policies on how to deprecate or
>>> remove classes from a Java EE API, which means
>>> that the final decision is up to the expert group. However the Java EE
>>> Specification, section EE.6.1.3 "6.1.3Pruned Java
>>> Technologies" (which discusses a different issue, that of removing
>>> entire technologies from Java EE), links to a Java SE
>>> policy described at [http://mreinhold.org/blog/removing-features],
>>> which appears to be a suitable policy to offer.
>>>
>>> That policy states that a particular version of a spec may state that
>>> a feature is "proposed for removal". This means
>>> that the following version can remove it.
>>>
>>> However that policy also states that "removal" of a feature does not
>>> mean actually deleting it. Instead the feature will
>>> remain in the specification but will become optional. This means that
>>> implementers are not required to implement it. Its
>>> tests will remain in the TCK to allow those who decide to implement it
>>> to verify that it has been implemented correctly.
>>>
>>> Other issues
>>> ------------
>>>
>>> Before making this change we should confirm that the
>>> "domain-independent" interfaces are a complete replacement for the
>>> "domain-specific" interfaces.
>>>
>>> It has been noticed that Session.createDurableSubscriber() returns a
>>> TopicSubscriber, not a MessageConsumer. This looks
>>> to me like a mistake which would need to be fixed before we could
>>> remove TopicSubscriber. The solution would be for this
>>> method to return a MessageConsumer. Since this is a supertype of
>>> TopicSubscriber it should not break existing applications.
>>>
>>>
>>
>>