Pete Muir wrote on 02/11/12 09:20:
>
> On 10 Feb 2012, at 19:11, Bill Shannon wrote:
>
>> Thanks, Pete.
>>
>> With regards to:
>>
>>> Finally, were a vendor to invent a clever way to handle this, as an
>>> optional extension, we could incorporate this into a later rev of Java EE
>>> without breaking backwards compatibility, which is always a good thing
>>> (don't preclude unknown futures).
>>
>> With option #1, all Java EE products would be required to detect the error
>> of using the new transaction annotations on an EJB bean. That would not
>> leave much room for a vendor to invent a clever way to handle this.
>>
>> Perhaps what you really want is that the behavior in this case would be
>> undefined, and that vendors would be free to "add value" by handling this
>> case differently? (Note that we generally tend to try to avoid such
>> situations because they kind of destroy the whole Write Once Run Anywhere
>> value proposition.)
>
> Agreed. What I was really thinking was a vendor might provide this an option
> that could be turned on (off by default) should a user want to use it - of
> course, this would be a spec-incompatible mode for the app server to run in.
>
> So, I would agree we define it as an error.
As I'm sure you're well aware, the Java compatibility rules don't allow
"spec-incompatible" modes *at all*.
If you want your product to do it, the spec has to allow it.