If people want read/write access to a variable then add it to inner classes along with short syntax for instances of an anonymous inner class. What I object to is something that isn’t an object and has different semantics that are going to be at best different than the rest and at worst just plain confusing.

What are the advantages of the different semantics, particularly the restriction that a BGGA closure doesn’t inherit?

Nobody said we would be _removing_ Inner classes. The limitation I see with Inner Class classes is actually the scoping of context variables. I know the CICE proposal wants to address just this by doing minor adjustments. I would however prefer a more concise syntax.

Yes extension methods (or mixins) are something I’d like to have as well. It would reduce the need to change existing API’s.

What is the advantage of new semantics that are less powerful than those we already have?

In order to get more powerful use from the new resources, some changes must be made in API. An example is your select method that could be part of the API. There is a lot of places where methods could be added to get advantage from new language features. Maybe, a required complement to Closures is Extension Methods (http://msdn.microsoft.com/en-us/library/bb383977.aspx). So, we will write code like this:

import extension java.util.CollectionsExtension; // I’m just illustrating my point here.

List wordsContainingK = words.select({String it => it.contains(”k”)});

Wow, almost Groovy, huh?

this works for all API methods eating single method interfaces. This is a good start; API's will follow later.

An example of such inconsistency is PHP: One can do OOP in PHP, but when the API itself isn't OOP, it's uncomfortable. (PHP sucks anyway, most inconsistent 'programming' language).

The API should act as an "example of good development concepts".
Typical scenario: "Hmmm, what's that language feature for? Hey, I just search the API and see how it's used there."

Break compatibility! Make Java 8 New features plus an API that uses them.

People are always afraid of change, but change is necessary to remain let alone to grow. I miss not having C# style properties in Java, i dont like the boilerplate code of anonymous inner classes for simply passing some lexically scoped code around. I dont like the lack of type inference and the resulting type duplication when using generics extensively. These things should be fixed.

Nothing is too late for JDK7. Some people are still on JDK 1.4 and start new projects with JDK 5 only. It is going to take some time till JDK6 is widly adopted. There is enough time to make a big and healthy step with JDK7.

Better yet (and certainly more controversial), create a way to deal with custom pre-processors (or macros). Let people distribute syntax extensions/translations the way jars are shared. Perhaps one out of 500 will be worth using...but it will open java up to a lot more experimentation.