+1
On Fri, Sep 16, 2011 at 10:25 AM, Nigel Deakin <nigel.deakin_at_oracle.com> 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.
>>
>>
>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com