Effectively final effective?

[Reinier Zwitserloot]

The way I understand JSR308, the only thing that's going to be integrated
into JDK7 is the ability to stick annotations on arbitrary types. The
Checker Framework right now already "allows" this by reparsing your source
with a custom build of JDK7 which parses this:

List</*@NonNull*/ String> x;

As if the annotation wasn't commented out. The actual checker framework
itself, as well as the batch of annotations + processors that ship with it
'out of the box', aren't going to be in JDK7, I'm pretty sure.

--Reinier Zwitserloot



On Thu, Feb 25, 2010 at 6:44 PM, Peter Levart <peter.levart at marand.si>wrote:

> 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
>