Nigel,
They should be deprecated.
Cheers,
Reza
On 8/15/2011 11:12 AM, 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!
>
> 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.
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3835 - Release Date: 08/15/11
>
>