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: JAVA-98: Proposed direction for resolution


The specification is currently inconsistent on whether annotations
are inherited.

The following annotations apply to implementation classes and are
defined as inherited:
   @Authentication
   @Confidentiality
   @Integrity
   @Requires

Note1: The specification isn't clear on the following points.
  a. whether a subclass can remove intents that were specified by
     its superclass.  [Proposal: allow this using a special
     ".none" form of qualified intent.]
  b. whether intents specified by @Requires on a subclass are
     merged with intents specified by @Requires on the superclass.
     [Proposal: they should be merged, with subclass intents taking
     precedence for the same intent type.]
  c. whether intents specified using @Requires on a subclass are
     merged with intents specified using specific intent annotations
     on the superclass (or vice versa).  [Proposal: they should be
     merged, with subclass intents taking precedence for the same
     intent type.]

The following annotations apply to implementation classes and are
not defined as inherited:
   @AllowsPassByReference
   @Callback (see note2 below)
   @PolicySets
   @Remotable (see note2 below)
   @Scope
   @Service

Note2: The spec is not currently clear on whether @Callback and
@Remotable can be applied to implementation classes.  I am raising
an issue to confirm that this is allowed.

It seems useful to allow inheritance of all the annotations in
the second list above.  If we do this, we need to ensure that
inheritance can be overridden in cases where it is not desired.

1. For @AllowsPassByReference, a value of false can be specified
    for a subclass that wishes to disable this marker.
2. For @Callback, the no-attribute form can be specified for
    a subclass that wishes to disable the callback interface.
3. For @PolicySets, the no-attribute form can be specified for
    a subclass that wishes to remove inherited policy sets.
    This implies that policy sets specified by a subclass
    completely override those specified by the superclass, with
    no merging.
4. For @Remotable, no mechanism currently exists for a subclass
    to disable this. {Proposal: add a boolean value attribute,
    similar to @AllowsPassByReference.]
5. For @Scope, a different value (or the default) can be specified
    by the subclass.
6. For @Service, the no-attribute form can be used by the subclass.
    {Proposal: remove the statement in the spec that this form is
    meaningless.]

I propose the following direction for resolving JAVA-98:

  Clarify the semantics of intent inheritance as indicated by
  [Proposal: ] under points a, b and c in the first list above.

  Add the @Inherited annotation to the definitions of all the
  annotations in the second list above.

  Make the changes indicated by [Proposal: ] under points 4
  and 6 in the second list above.

If this direction is accepted by the TC, I will produce a
detailed list of spec changes with proposed text.

   Simon




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