Description Wes Isberg 2004-02-17 12:31:18 EST

Coming off bug 52105, these are some proposals for doc clarification and
possible enhancements wrt static initialization involving fields declared in an
aspect.

(1) During static initialization, expressions can only use static fields that
have been defined, which means order should be defined, but AFAIK, we have not
defined an order in the semantics.  It seems possible for an implementation to
order field initialization so it works (and warn on cycles), but the order
should probably be defined as the order in which they appear in the types
declaring them.  The order between types probably should be undefined, but could
be defined by precedence (which suggests that classes should be permitted in
declare precedence statements).

(2) Currently, static ITD fields can be defined in their declaration or in
advice on static initialization, which limits the expressions available for
final fields and makes initialization of such fields awkward.  So perhaps an
aspect should be able to declare a static initialization block on another type,
something like:

    TargetType.<clinit>{
       ... init code
    }
 
? init code" might have to be restricted in some way?
? "TargetType.new {}" -- distinct from instance in having no ()?

This makes possible complex mutual definitions, e.g.,

   public static final Target.List ALL;
   public static final Target.List ONE;
   public static final Target.List TWO;
   Target.<clinit> {
       ArrayList list = new ArrayList();
       ONE = new Something("one");
       TWO = new Something("two");
       list.add(ONE);
       list.add(TWO);
       ALL = Collections.unmodifiableList(list);
   }