What are the fundamental problems?

Like MS, the new Java lives well with other languages.  Pretty soon we'll all
be singing at La Scala, I wager.

Puns aside, given the ability to blend with other languages, and its use of
non-functional idioma like anonymous inner claases to replace "true closures"
(everybody pause in reverence), there's no real reason for Java itself to
change.  Java  doesn't need to be the ideal language - just blend it with a
JVM-ized Rhino or Scala or what-all.  If the typical Java way doesn't suit,
you divide your app along domain boundaries that lend themselves to transition
into other languages.

Even that might not be necessary.  The Java idioms actually do support
creation, on time, of software that will fulfill requirements with
reliability.  While inner classes are a bit tricky and arguably ugly, they
work for pretty much anything you need, and frankly, are easier to read and
understand as a maintainer.  Closure syntax is slick as all get-out, surely it
is, but it's got its own readability challenges.

The object oriented syntax of a Java anonymous inner class can be made to work
for you, both for the self-documentation nature of the source and to help the
Hotspot optimizer see opportunities.  You see an override method, like
accept() for a FileFilter, that is going to iterate its operation over a whole
set of candidate File entries.  Very closure-like.  But instead of a mathlike
formula mapping a file to a boolean, you have a function-like accept() with
words describing the logical condition for the acceptance.  Those words will
refer to a private method that progressively shows more detail, thus not
hiding the purpose in a complex algebraic expression.

All in a hairy anonymous class declaration.  Except, not so hairy as all that
really, once one's actually trained oneself as a competent Java programmer.

So what if the Java inner-class idiom is but a clumsy, unsophisticated
workaround for the pristine elegance of true closures, and lacks in certain
arcane reaches - Java reaches far enough to get the job done.

Bloch--I would prefer to use the last name in this discussion, as
`Joshua' is an extremely common name and two people with said name are
now going to be involved in the discussion--notes at one point that the
decision to not make the primitive types extend from Object was perhaps
a bad one. Indeed, some of his dislike for BGGA closures comes from its
inability to handle auto{un}boxing.

True, pure functional programming (at least as Wikipedia describes it)
cannot succeed in Java:

Functional programming ... treats computation as the evaluation of
mathematical functions and avoids state and mutable data.

Since object-oriented programming emphasizes encapsulation of state and
mutability--indeed, methods without side effects should be rare in
OOP--functional programming is the exact antithesis of this. Even if
functional programming is the new "in" in programming, Java is, always
has been, and always be OOP; forcing this new paradigm onto it would be
painful and ultimately (IMHO) fatal.

But Bloch also points out that closures seek to solve several problems
(perceived or real) in Java:
1. Verbosity in anonymous inner classes
2. Difficulty in instituting callback
3. Inability to create pseudo-control structures
4. Verbose and error-prone resource management
5. Difficulty in parallelization

Closures, at least in the BGGA proposal, are the poorest way to tackle
all of these:
1. Verbosity is traded off into short-but-confusing code snippets.
2. Function pointers are helpful, but they are prone to extremely poor
documentation. Syntax is also barbaric.
3. The only two pseudo-control structures that seem to be pondered are
the ARM blocks similar to C#'s using and multivariate for loops. Of
these, the former could be solved with a simple syntactic-sugar
modification, and the latter isn't terribly high on my list of things
that I need. Tackling this also creates the most complexity.
4. See answer to point #3.
5. I don't really see how BGGA solves this problem.

I recall browsing a BGGA closure discussion which brought up that a
     return
can be different, in some cases, from a
     return;

The discussion here was telling. One proponent was saying that the
difference between the two can be easily remembered because the
semicolon version is doing a non-local return and the other the local
return (closures returning void are SERIOUSLY confusing). If the
presence or lack of the basic statement delimiter has two different
/compilable/ effects, then the proposal is *seriously* flawed.

Here I am also mostly in agreement with Bloch on this four points:
1. Not that much of a problem. Modern IDEs make it extremely easy to cut
through all of the overhead code. I don't use a modern IDE, but I abuse
the anonymous inner class syntax, and I don't complain about it's
verbosity. Au contraire, it can be beautiful.
2. Function pointers will do more harm than good unless done right. And
I don't really see how they can be done right.
3. Pseudo-control structures begin to risk fracturing Java into dialects
much the way C has. I see very little use for these structures, except
for...
4. ... this one. And Bloch's idea to solve this is good enough for me.
5. Simple but powerful parallelization techniques are still in the arena
of cutting-edge research. And I believe that what is research does not
belong in a production language.

Everything said, I believe that closures present a problem for Java. A
large community seems insistent on pushing closures into Java at the
expense of tackling other problems. I believe that the problem of
generics need to be solved before any other new feature can gain entry.
But the efforts that could be used to best fix these problems are going
into presenting three or four conflicting versions of closures and
expanding these versions to make Java more functional.

I, on the other hand, was not surprised: Bloch points out near the
beginning that Java was designed to be an operational language, a mixed
language (I forget his exact wording) as opposed to the research
languages. It seems to me that he is of the opinion that languages like
Scala are designed to be researched on, that is, to be sliced, diced,
cut, and mutilated for the purposes of deciding which features should
and should not be placed into a new language. It is in this vein that I
think he intends to recommend Scala.

I do believe that someone has already built such a thing. However, I am
going to bring to mind one blog praising "The Next Big Language". What
will it be? Ruby, Javascript, Groovy, and others were tossed around
without consensus. But these languages are all similar in one way: they
gain a sizable following, generate a fair amount of hype, and then...
nothing happens. What industry really needs is for there to be one
language that specializes and focuses in this new area without strong
competition as opposed to competing jack-of-all-trades. After all, who
makes more: the master goldsmith or the jack-of-all-trade smith?