[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] JAVA-129: Proposed resolution
Thanks for the table, it's very illustrative. This is one reason why I think working with examples is helpful. Can I go on record now expressing strong dislike of the JSR250 rules?
While the example is contrived and artificial to illustrate the effects of JSR250 works, it none-the-less shows the complexities. One aspect in particular that really jumps out is the effect of a method level annotation on other methods, producing side effects that will be easily overlooked.
Let's look at the helloThere method. Suppose the helloThere method was added to the HelloChildService and the implementation simply delegated to the super class. The table shows that there is a significant difference between helloThere as it exists in the HelloService and this new helloThere which is essentially the same service method! The changes occur simply due to collocation of the new helloThere method with other methods in HelloChildService. Ouch!
I'm now strongly reconsidering whether we should support any annotation inheritance.
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
Simon Nash ---03/17/2009 05:49:14 AM---After considering various approaches to fixing the listing in example 2b, I decided that replacing i
From: | Simon Nash <oasis@cjnash.com> |
To: | OASIS Java <sca-j@lists.oasis-open.org> |
Date: | 03/17/2009 05:49 AM |
Subject: | [sca-j] JAVA-129: Proposed resolution |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]