JavaMemoryModel: final isn't used much in the JDK, even when it could

From: Bill Pugh (
Date: Wed Jul 21 1999 - 11:49:14 EDT

I did some checking. In the JDK, considering only fields that
are non-static, non-public, non-protected and non-synthetic,
we have

3122 are not final
2187 are not marked as final, but could be
 105 are not modified by any bytecode, probably modified
        by native code
 790 are marked as final

For the fields not marked as final but that could be,
there are modified in constructors but nowhere else
(although I didn't check native code). To actually mark
them as final, you might need to modify the code to ensure
that they are written to exactly once (in some cases (e.g.,
java.lang.String) the fields are written to multiple times
in the constructor).

Looking at classes, we have:

1139 immutable classes
1307 mutable classes

(In the above calculation, I've only included classes that have non-static
fields. If a field is protected, public, modified outside of a constructor,
or not modified at all by bytecode, then the class is considered mutable.)

So two points for discussion:

  Does anyone have a feel for why final is used so rarely? It certainly
        seems like it could be used much more. It might be very useful
        to a compiler to know that the field is final (then you can know
        that it won't be modified by a method call).

  There are a lot of immutable classes. If we decided to guarantee
          initialization safety only for immutable classes, that still
        leaves us with almost half of the classes to protect.

This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.

To send a message to the list, email
To send a request to the list, email and put
your request in the body of the message (use the request "help" for help).
For more information, visit

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