Library Solution possible? (was: Nice to @Share?)

[Gernot Neppert]

2010/2/22 Joshua Bloch <jjb at google.com>:
> that are not final or effectively final. This requires programmers to use
> the well-known single-element array (or wrapper object) idiom in the rare
> case where they really do want to close over a mutable local variable. If we
> decide that we really must provide a more concise syntax (and I'm not at all
> sure that we should), then I believe a new modifier is justified (not an
> annotation), and that "shared" is a poor choice of name. I'm not sure what a
> good name would be, but I won't think about until we've decided that we
> really want such a thing. Think of it as lazy evaluation;)

I'm also not convinved that we need a more concise snytax for
capturing non-final variables at all.

Quite rarely have I've been wanting to modify a local variable from
within an anonymous inner class.
Half of them have been asynchronous invocations, and that was before
the advent of the Executor-framework in Java 5 with its concept of
"Futures".
The other half were synchronous "closure-like" Predicates or
Transformations in order to process Collections, and those were almost
always completely free of side-effects, which I consider good practice
anyhow, BTW.

In the rare remaining cases I was sometimes tempted to (ab)use the
"Holder" classes from the package org.omg.CORBA.
This makes me ask:
Can we come up with a Standard Library solution for mutable local objects?
Something like "java.util.MutableVariable<T>"