Re: JavaMemoryModel: Java Class initialization can deadlock?

From: Joshua Bloch (
Date: Thu Mar 20 2003 - 11:57:59 EST


   Laudable as this goal is, I think it's too late. It will change the
behavior of existing programs in ways the customers won't find
acceptable (even if they should). The JLS is quite explicit about the
behavior under these circumstances and I think we're pretty much stuck
with it.


P.S. I think there may be a typo in your second example: there is no C.y .

Doug Lea wrote:

>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.
>JavaMemoryModel mailing list -

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT