### §1.2.1 Modifiers for roles

Member classes of a team cannot be `static`. Also the use of access modifiers for roles is restricted and modifiers have different (stronger) semantics than for regular classes (see below). With respect to accessibility a team acts mainly like a package regarding its roles.

#### (a) Role class protection

A role class must have exactly one of the access modifiers `public` or `protected`.
This rule does not affect the class modifiers `abstract`, `final` and `strictfp`.

#### (b) protected role classes

A `protected` role can only be accessed from within the enclosing team or any of its sub-teams. The actual border of encapsulation is the enclosing team instance. The rules for protected roles are given in §1.2.3 below.

#### (c) public role classes

Only `public` roles can ever be accessed outside their enclosing team. Accessing a role outside the enclosing team instance is governed by the rules of externalized roles, to be defined next (§1.2.2).

#### (d) abstract role classes

A role class has to be marked abstract if any of its methods is not effective.
The methods of a role class comprise direct methods and methods acquired by inheritance. In addition to regular inheritance a role class may acquire methods also via implicit inheritance (§1.3.1).
A method may become effective by either:

- implementation (i.e., a regular method body), or
- a callout binding (see §3).

§2.5 discusses under which circumstances abstract roles force the enclosing team to be abstract, too.

#### (e) Role features

Access modifiers for members of roles have some special interpretation:

1. A private member is also visible in any implicit sub role (see implicit inheritance §1.3.1.(c)).
   In contrast to inner classes in Java, private members of a role are not visible to the enclosing team.
2. The default visibility of role members restricts access to the current class and its sub-classes (explicit and implicit).
3. `protected` role members can only be accessed from the enclosing team or via callin (§4).
4. `public` role members grant unrestricted access.

Additionally, a role always has access to all the features that its enclosing team has access to.

Only `public` members can ever be accessed via an externalized role (§1.2.2).

#### (f) Static role methods

In contrast to inner classes in pure Java, a role class may indeed define static methods. A static role method requires no role instance but it still requires a team instance in scope. Static role methods can be called:

- from the enclosing team,
- via callin (see §4.7).

Within a static role method the syntax `MyTeam.this` is available for accessing the enclosing team instance.

#### (g) No static initializers

A static field of a role class must not have a non-constant initialization expression. Static initialization blocks are already prohibited for inner classes by Java (see JLS §8.1.2).

##### Note:

Static initialization generally provides a means for performing initialization code prior to instantiation, i.e., at class-loading time. Before any role can be created already two levels of initialization are performed: (1) The (outer most) enclosing team class performs static initializations when it is loaded. (2) Any enclosing team executes its constructor when it is instantiated. It should be possible to allocate any early initialization to either of these two phases instead of using static role initializers.