[otj-users] [Bug ?]: static final constant in role not initialized/error

[Stephan Herrmann]

Hello,

> what about a public static final constant inside a role class,

static elements in inner classes are indeed special. 
Note that in similar situations javac simply says:
	"inner classes cannot have static declarations"
That would be the simple way, but people seem to want statics
within roles, so let's see how far we (have) come:

> that is initialized via a static method of that role or the role's base.
> Is this OK? (OTDT shows no warning etc.)

That was a bug: you should have seen this error:

1. ERROR in test/TeamB11ch5c.java (at line 11)
public static final String string = getLocalString();
                                    ^^^^^^^^^^^^^^^^
Non-constant initialization not allowed for a static field of a role class (OTJLD 1.2.1(g)). 

This error was only detected for private fields, fixed in SVN.
Thanks for the test case (is now  B.1.1-otjld-ch-5c,
http://www.objectteams.org/distrib/jacks/1.0.0/results/B.1.1-otjld-ch-5c.html)

> If yes, one gets
>  - a java.lang.VerifyError, when the method is a role member

This is because the compiler attempts to generate a <clinit> method
(static class initializer), which doesn't harmonize with roles and especially
implicit inheritance.

> If no, the OTDT should show an error marker. :)

it does now.
I will in a minute start building a release candidate for 1.0.0.
The bugfix will be included. I'd like to ask you then to verify whether the
error is correctly reported in your project.

Also, I'd like to hear comments on the general situation of statics within roles.
The complete solution would support these four levels of fields:

1. static team fields
	-> exactly one value per system
2. team member fields
	-> one value per team instance
3. static fields of roles
    Since the type of a role R always depends on some team instance t,
    each R<@t> is a new type, i.e., static fields have one value per R<@t>
	-> one value per team instance
    ;-)
4. role member fields

Note that for methods all four levels are correctly supported (static role methods
indeed have access to an enclosing team instance). Test B.1.1-otjld-ch-5d
http://www.objectteams.org/distrib/jacks/1.0.0/results/B.1.1-otjld-ch-5d.html
demonstrates how this can be done.

Techically, field levels 2. and 3. are redundant. For practical reasons,
we do support constants to be declared in roles, too. Unfortunately, this
does not work if you initialize the field from a non-static expression like
a method call.

So currently, if you can't provide a static initialization expression (i.e., an
expression that can safely be inlined), I must ask you to use a team field
instead (static or non-static, you choose). 

Is that a major limitation?
We could let the compiler do that for you (i.e., you write a static role field,
the compiler transparently transforms it to a team member field), but that
is quite an effort to pay, which I'd like to avoid at the current point.
How important are static role fields beyond simple constants for you?
(I'm asking every body on this list).

thanks for bringing this up,
Stephan