Effectively final effective?
reinier at zwitserloot.com
Thu Feb 25 09:28:20 PST 2010
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
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.
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
> 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
> > it into lambda-dev.
> Would a '@Safe' qualifier as a JSR 308 checker plug-in be enough to warn
> against 'unsafe' functions?
More information about the lambda-dev