On 25/10/2011 16:47, Clebert Suconic wrote:
> Wouldn't that be an arbitrary decision?
>
>
> EJB had their chance to make a lot of improvements between 1.1 and 2.0
>
> If we take too hard on compatibilities, we make take the risk in JMS2 becoming 1.2, 1.3... etc.
>
> And I think the idea is JMS *2.0*
>
> We could still have the old model, and create a new package for new applications, just like EJB 2 had done in the past.
>
>
> JMS is a pretty old spec. We could do a lot of improvements on it with current API standards.. etc
I don't think I responded to this directly.
The guidelines I drafted have now been moved to the Java EE platform wiki at
http://java.net/projects/javaee-spec/pages/CompatibilityRequirements
There's a small extra paragraph about changing the behaviour of exceptions (which the Java EE spec lead added) and a
couple of mentions of JMS have been deleted. but otherwise it's the same document as before.
From what I've been told, these requirements are describing what has been longstanding policy that has hitherto only
existed in "folk memory". However the wording is new so it might be possible to improve or clarify it if we feel that to
be necessary. It does, I think, accept that some areas are nuanced and require careful consideration.
We're the first expert group to see this document, since I wrote the first version of it following a interview with Bill
Shannon. I think he will present it to the Java EE platform group in due course. I'll look out to see how it is
presented, whether there is debate on it , etc.
As I think I mentioned in another thread, these requirements don't prevent us devising a completely new API worthy of
the "2.0" suffix. However it means that if we decide to do that we would need to make it additional to the existing API
(e.g. a completely new package) rather than changing the existing API.
Did EJB 2.0 introduce incompatible changes? Doesn't all the old stuff still work?
Nigel