Effectively final effective?

[Peter Levart]

On Thursday 25 February 2010 18:28:20 Reinier Zwitserloot wrote:
> Er, I guess. So, "safe" means that the _closure_ is safe to be transported
> into different threads, and "unsafe" means that the closure cannot be
> transported?
> 
> I tend to think from the side of the callee, so I mixed them up.
> 
> Until every Joe, Tom, and Mary java programmer run the checker framework, An
> "@Safe" qualifier isn't going to change the notion that doing unexpected
> magic (either turning a variable into a heap-allocated concept, _or_ making
> an implicit copy) is going to result in folks spending many hours hunting
> for obscure bugs.

As I understand, JSR 308 will be integrated into JDK7 and '@Safe' checker could be enabled by default. The writers of concurrent execution frameworks (such as fork/join or ParallelArray) would just have to mark their APIs with '@Safe' annotations and a special checker's AnnotatedTypeFactory would analyze the AST to deduce implicitly if a particular function-typed expression is @Safe or not...

> 
> Also, if a variable is turned into a heap allocation, does it then become
> legal to put "volatile" on a local variable declaration? What should happen
> if a variable isn't hoisted into the heap? Just ignore the volatile? Emit a
> warning or error that this isn't making any sense?
> 
> What's so bad about either a keyword ('public', 'nonfinal', 'modifiable', or
> some such), or usage of AtomicReference (both of those explicitly pointed
> out by the compiler/IDE error message when you attempt mutation of an
> implicit final)? Without safe / unsafe closures, one must presume closures
> are not restricted to the current thread, and as a result making a variable
> mutable and shared across the closure boundary is a very very big deal, and
> warrants some sort of explicit flag.
> 
> --Reinier Zwitserloot
> 

Peter