Nigel,
I believe this is the right way to go. These interfaces should be
deprecated. I would also like to propose that any new functionality we add
note that these interfaces are deprecated and avoid make any changes to
these interfaces and not support these interfaces.
John
On Mon, Aug 15, 2011 at 11:12 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> I have logged the following issue:
> http://java.net/jira/browse/**JMS_SPEC-47<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!
>
> 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<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.
>
>
>