Effectively final effective?

[Reinier Zwitserloot]

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.

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



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

> On Thursday 25 February 2010 17:44:44 Reinier Zwitserloot wrote:
> > It's still more than a month until April 1st.
>
> Sorry, It was another bad idea. I apologize.
>
> Now, seriously:
>
> > ....
> >
> > NB2: Without an explicit 'safe / unsafe' closure concept, turning local
> > variables into heap-allocated non-thread safe variables is a major change
> > and something that you should always be careful with. *with* an explicit
> > 'safe / unsafe' closures concept, the solution is of course to state that
> > safe closures may mutate variables from their enclosing scope, and for
> the
> You meant 'unsafe', didn't you?
> > compiler to sort out how to make it happen. This idea is therefore either
> > dangerous or unnecessary, depending on if safe/unsafe closures somehow
> make
> > it into lambda-dev.
> >
>
> Would a '@Safe' qualifier as a JSR 308 checker plug-in be enough to warn
> against 'unsafe' functions?
>
> Peter
>