On 18/05/2012 19:33, Clebert Suconic wrote:
> Well, I just talked to Jason Greene, Application Server lead at JBoss,
> and he's part of a few EE specs...
>
> "They really dont deprecate much. There is a pruning process for
> making certain specs optional. So the best way to go about this would
> be to define JMS 2 as being radically different, and then prune JMS 1
> in the EE spec which includes JMS2 for that to happen a majority vote
> must pass. Then it takes an entire new rev of the EE spec before its
> removed. Example JAX-RPC was pruned in EE6, removed in EE7"
>
> We would need to make JMS2 a separate spec, and make JMS1 optional,
> and still pass a majority vote on doing it.. i.e. I don't see it
> happening:
Yes, this matches my own understanding of what the pruning process is for.
> So, I guess we are really stuck with those interfaces as you said.
> It's sad though.. it would be nice to have something on the process
> allowing such things.
>
> Anyway, I'm all for adding notes on the javadoc about avoid using
> them. At least we should help people to move out of these domain
> specific APIs.
Yes, I'll definitely add a note to the javadocs. I'll also try to rework the spec to give the correct emphasis (it
currently focusses on the domain-specific APIs).
I'll draft the changes and give this EG an opportunity to review what I have written.
It's worth remembering, though, that although the domain-specific interfaces have been superseded by their supertypes,
they still work perfectly well and offer (almost) full functionality. They're not incorrect, unsafe or non-portable
(unlike the BASE64Encoder class John A. mentioned). The main reason we want to remove them or discourage their use is
that they make the JMS API seem more complicated than it really is. I hope that suitable wording can help overcome that.
Nigel