

Closures for Java - past
http://blogs.sun.com/mr/entry/closures

======
maddalab
In the absence of the ability to capture non-final variables, the proposal
does not add closures to Java, only 'function-literal syntax' for specific use
cases, or for the java community 'anonymous-function' is lieu of more verbose
'anonymous-classes'

------
nradov
The is a positive step, but the lack of control abstraction is a terrible
shame. With control abstraction I could really cut down the boilerplate code.

------
moe
Too little, too late.

~~~
kls
Why, There a lot of organizations that have allot of invested time, training
and code-base in Java. Even if no new features where added to another Java
application, adding closures to ease the maintenance of existing code is
justifiable enough.

Like it or not Java is the enterprise language and Ruby, Scala, Haskel et.al.
are not going to take that crown any time soon, just as it took Java a long
time to supplant COBOL, one of them will have to grind it's way in inch by
inch. The fact of the matter is that for what Java is intended for, it does a
very good job so it is not in the same seat that COBOL was.

I dislike Java (from a personal enrichment perspective) as much as the next
guy, but it is never too late to improve a language with such a useful
feature, especially a language that is going to be the dominate language for
the foreseeable future.

~~~
mechanical_fish
_it is never too late to improve a language with such a useful feature_

I have a different hypothesis. Every feature you bolt on decreases the
learnability of your language, decreases the navigability of your
documentation (the books are now 20% thicker, and the old books and web pages
are now useless), and decreases the odds that two programmers who "know Java"
can actually read each other's code.

It is also very hard indeed to introduce a new feature while preserving the
functionality of existing code. The gyrations and compromises that are
required are often enough to destroy most of the value of the new feature.
Better to build a new system around the feature and let it shine, not struggle
to fold a bastardized version of it into the old system.

The time to tinker with your system is when it is young. When the system is
old, and people have already built their lives around it, it is too late to
remodel the foundation. You can take this principle too far [1] -- it is
important to enjoy your youth fully, not settle into premature senescence --
but any system which becomes popular will sooner or later reach maturity.

Eventually your codebase, installed base, community, and documentation reach
the point where every time you change something important, you lose more in
coherency than you gain in power. [2] At that point your system is mature. The
best thing you can do at that point is to accept the facts of life and let the
system settle into its role -- preserve the value of the work you've already
done, the books and lectures you've already written, the people you've already
trained; then build on that work by calling its APIs -- while working on a new
system on the side. Because it is, in fact, often better to have two or three
smaller, comprehensible systems with fundamentally different features and
maturity levels -- Erlang for the telephone exchange, Lisp for the airline-
schedule AI, PHP for the three-line CRUD web page -- than a gigantic system
that is constantly remodeling to add more corner cases, like the Winchester
Mystery House.

Of course, Java's designers have never believed this hypothesis, or they would
have left well enough alone years ago.

\---

[1] As in the legend of the "make" syntax, which supposedly remains broken
because, by the time the designers realized it was broken, they already had
ten users and felt it was too late to fix. Don't worry about the first ten
users. By the time you have a million users, however, it might be time to
start thinking about stability.

[2] Think: _Windows_. It's mature. It no longer seems to be possible to make
major changes in the fundamental structure of that operating system. And
that's not necessarily a bad thing, unless Microsoft insists on trying,
spending billions of dollars and most of a decade and breaking a lot of
existing infrastructure in the process.

~~~
ldh
I somewhat agree with you in that Java should have made bolder moves earlier
on to provide some of these features and not lash itself to a bunch of
backwards-compatibility cruft.

And maybe a bunch of language changes right now will muddy the water a bit -
but as far as I can tell, most of the new language features in Java 7 will cut
down considerably on boilerplate and unnecessary verbosity, which should go a
long way toward making code _more_ understandable, which will be a breath of
fresh air.

If a little bit of altered syntax like what's being proposed is enough to make
anyone's head explode, maybe they should reevaluate whether software
development is really for them. And if your enterprise's codebase and culture
isn't ready for language changes, nobody is going to force you to switch to
Java 7.

