Planned improvements to multi-catch and more precise rethrow

[Joe Darcy]

We've been working on some improvements to the multi-catch with more 
precise rethrow feature [1] and are planning to push the changes soon.  
First, as long as a catch parameter is *effectively final* (in other 
words not reassigned inside the catch block), the more precise analysis 
will be enabled if the exception is rethrown.  An explicit "final" 
modifier will no longer be needed to enable the more precise analysis.

As pointed out in the original proposal form for "Improved Exception 
Handling for Java," [2] the more precise exception analysis can cause 
programs that currently compile to stop compiling since more unreachable 
code is identified.  While the general evolution policy of the JDK [3] 
does not promise source compatibility across releases, gratuitously 
breaking compatibility should be avoided.  Fortunately, after examining 
millions of lines of code in a diverse set of code bases, include the 
JDK, no instances where the more precise analysis would cause an actual 
source incompatibility were found.  (Details of the analysis will be 
written up later.)

Second, the catch parameter of a multi-catch clause ("catch(Exception1 | 
Exception2 e) {...}") will be regarded as implicitly final; the compiler 
will reject code that writes to such a catch parameter.  Consequently, 
an explicit "final" modifier will no longer be needed in this case, 
although it will remain legal.  This provides a more concise syntax for 
multi-catch in JDK 7 while preserving flexibility to more fully support 
disjunctive types in later JDK releases.

-Joe

[1] http://blogs.sun.com/darcy/entry/project_coin_multi_catch_rethrow
[2] 
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html
[3] 
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy