OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Two ways to specific the same intent


On the last call we had a short discussion about whether we should keep 
our current dual way of specifying annotations. Someone (I think Simon) 
had asked for an example. Here is one:

For the 'confidentiality' annotation, currently one can use either the 
@Requires or @Confidentiality, here is how the two look:

@Requires({CONFIDENTIALITY})

vs.

@Confidentiality


Note that all sca defined intents are defined as constants and we 
encourage creators of new intent-specific annotations to define 
equivalent constants. The above example is based on existing 
definitions, obviously the number of characters one has to type depend 
on the intent definition and the strings used for defining the constant 
(eg, MESSAGE vs. MSG). Also note that when using multiple intents the 
number of extra characters (the "Requires" part) are amortized over all 
the intents. Eg: @Requires({CONFIDENTIALITY, INTEGRITY})

My preference for getting rid of two ways to do the same thing is based 
on the following:

1) Multiple ways to do the same thing is usually not a good idea, IMHO, 
unless there is a significant advantage. The number of extra characters 
here doesn't seem to justify (to me) defining a bunch of new 
annotations, and @Intent @Qualifier.

2) In figuring out which intents are applicable, one has to merge the 
@Requires with intent-specific annotations to get the full set. Makes it 
slightly harder wrt understanding the code and its intent (pun intended 
;-) ).

3) This makes inheritance issue complex (I know there is a proposal to 
get rid of it, but I'm not convinced (yet) that this is best proposal, 
though can live with it. And even if we remove @Inherited, un-overridden 
methods still get the annotations from the superclass). What happens if 
@Requires is on a class and @Confidentiality is on a method (or vice 
versa) ... and there is inheritance. We get into exactly the kind of 
situation that JSR 250 talks about wrt @WebMethod and @WebService. I 
find that unintuitive and hard to remember.

-Anish
--


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]