capturing (or not) mutable local variables

[Jim Mayer]

@Howard,

I think that different people are coming from different places.  It does
seem pretty clear where Oracle wants to go with this.

In my case, the processors I'm deploying on are in (large) embedded systems
and are all single-core today and the calculations we're doing are
non-numeric.  There's a large UI component to what we do as well, so much of
what we do HAS to be on a single thread.  I'm interested in Java mostly
because it is "clean enough" so that high quality development environments
are available for it.  Working in Java is vastly more effective for us than
working in C++, and the bulk of that comes (I think) from the development
environment.

Unfortunately, Java is also resource hog.  Much of that comes from the
design of the libraries and of class overhead.  Class overhead isn't a big
deal for classes that are large or are used in many places, but it is
significant for anonymous inner classes and, probably, for the lambda-like
objects being discussed here.  One of the things I was hoping for from the
closures effort was a closure object that was much lighter weight than an
anonymous inner class.  If you don't believe that this is significant, then
I suggest that you look at the reflexion heavy contortions that folks doing
data binding (JSR 295 and similar approaches) go through to avoid it (e.g.,
'BeanProperty.create("propertyName")').  I know the issue has been discussed
extensively (e.g., http://java.sun.com/docs/white/delegates.html), but it's
not clear to me that anything much has happened in that area.

Finally, features that rely on a VM as sophisticated as Hotspot for adequate
performance are a real problem in my application space.  Although hotspot
JVMs have a big footprint, the real issue is that they're not even available
for the processors we use.  Shark may get there someday, but it's not stable
now.

As for the points you raised:

(1) I agree that it's compatible with what Java does now.  That limitation
was one of the first things I noticed when anonymous inner classes came
along.  I remember being rather surprised at the time, since Sun had lots of
people who were well aware of what other languages had (successfully) done
with similar features.

(2) Well, volatile doesn't really help with read/write thread safety issues
anyway.  A "safe" read followed by by a "safe" write still leaves an unsafe
transaction.

(3) If the goal is to be able to pass lambda expressions to APIs without
knowing whether the API could use parallel execution then I think we'll be
very disappointed.  Given the mutable state history of Java, APIs will need
to be explicit about what they plan to do with closures/interfaces/etc. that
they are passed.

(4) I guess I still don't see the problem with marking API entries with
"@Pure" annotations (or something like that), and letting the compiler
generate warnings for problematic usage.  It's not necessary for the
warnings to be complete for them to be useful.

Anyway, that's the background I've been coming from.

Cheers!

-- Jim

On Mon, Nov 22, 2010 at 2:57 AM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> @Jim & Llewellyn,
>
> You raise a number of points:
>
> 1. To me the proposed lambdas are consistent with Java, in particular
> with inner classes (which also only close over finals). The type of
> the lambda must be a SAM, which means it could be an instance of a
> class (including inner class) or a lambda, therefore it is important
> that something written to work with an inner class works with a
> lambda.
>
> 2. As others have pointed out fields can be marked volatile and locals
> can't, which helps in making a lambda thread safe when writing to a
> field (and it would be hard to add volatile to a local).
>
> 3. In Haskell a closure that interacts with mutable state via a monad
> can't, in general, be passed to a non-monodic function or vice versa
> (and this can be a pain and is an active area of research in the
> Haskell community to remove this restriction). In the proposed lambda
> model you can pass the lambdas freely to anything, that is a nice
> feature (you don't need to know the details of the function you call).
>
> 4. I agree that Java isn't the ideal parallel language, but lets learn
> from the mistakes of others and move away from mutable state and set
> Java up as better than C#, Scala, Lisp, etc. in the parallel domain.
> Tell people that if they want mutable state they should use AtomicXXX
> to guarantee thread safety. It is a pity that Java didn't make
> everything immutable in 95 and that you have to mark stuff as mutable
> using AtomicXXX (however this is looking back 15 years and it is very
> easy to spot mistakes in hindsight and the fact is that Java was much
> better than anything else in 95 and did provide state of the art
> parallel constructs for 95).
>
> Cheers,
>
>  -- Howard.
>
> On 22 November 2010 17:39, Llewellyn Falco <isidore at setgame.com> wrote:
> > I also want to point out that there seems to be an assumption that the
> > consumer of the lambda has ANY idea that creator of the lambda USED a
> > lambda.
> > Remember that the signature for someone using a lambda will be like
> >
> > public <T> List<T> where(Func<T,Comparable> f)
> >
> > The fact that you created the Func SAM interface with a lambda is not
> known
> > to the user of the lambda.
> > Therefore, the idea that some of the creations might be thread safe,
> isn't
> > very useful.
> >
> > Llewellyn
>
>
>
> --
>   -- Howard.
>