First: This is in scope of JSR-133 because it includes the case of
(static) finals, right?
I don't have a concrete suggestion about this, but one approach to it
is to first carefully define the ideal state of affairs in which all
true unresolvable circularities involving static finals throw
InitializationCircularityError and no others do.
For example, one that should throw InitializationCircularityError is:
class A { static final int x = B.y + 1; }
class B { static final int y = A.x + 1; }
I made up exception name since no other defined java.lang exceptions
seem to fit. "ClassCircularityError" is an appropriate name but used
for different purposes. The exception is surely better than either
deadlocking or nondeterministic initialization.
And one that shouldn't is:
class A { static final int x = C.y + 1; }
class B { static final int y = A.x + 1; }
class C { static final int z = 1; }
In part because their initialization can contain only constants, reads
of other statics and calls to static methods, it seems that in
principle you could always detect true fine-grained circular
dependencies for static finals well enough to throw exception before
deadlocking, but at far too great a cost to require. I don't at the
moment see a path for weakening analysis burden/overhead but still
meeting ideal goal though.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT