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

[Reinier Zwitserloot]

Sure. It already exists though:

java.util.concurrent.atomic.AtomicReference<V>.

Yes, you get the extra 'baggage' of the thread safety in the .get() and
.set() methods that AtomicReference has, but this would seem to be a good
thing, given that by sharing across lambdas you open the door to threading
issues. On the other hand, past experiences in java have always resulted in
creating a mirror non-thread-safe object (StringBuilder vs. StringBuffer,
ArrayList vs. Vector, HashMap vs. Hashtable), for performance reasons.

I always use AtomicReference (or AtomicInteger and variants) when I need
mutable access to parent scope from an anonymous inner class literal.

--Reinier Zwitserloot



On Tue, Feb 23, 2010 at 9:33 AM, Gernot Neppert <mcnepp02 at googlemail.com>wrote:

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