madbean

There have been some intersting comments by Guy Steele on the ll1 maillist regarding design decisions in Java. Tidbits follow.

You know how local variables or arguments that are “captured” by an inner class need to be declared final? Well, it originally wasn’t going to be that way. We would have had “closures”:

Guy Steele wrote:
Actually, the prototype implementation *did* allow non-final
variables to be referenced from within inner classes.  There was
an outcry from *users*, complaining that they did not want this!
The reason was interesting: in order to support such variables,
it was necessary to heap-allocate them, and (at that time, at least)
the average Java programmer was still pretty skittish about heap
allocation and garbage collection and all that.  They disapproved
of the language performing heap allocation "under the table" when
there was no occurrence of the "new" keyword in sight.

Maybe we could lift that restriction in the next few years...
I dunno.

But it might come back in the future:

Guy Steele wrote:
One of the early design principles of Java was that heap allocation
occurrs if and only if a construct involving the "new" keyword is
executed.  Adding full-blown closures violated this design principle.
(Dynamic class loading also violated the principle, but users seemed
to be comfortable with that, perhaps because they believed that
"once the computation got going" no more heap allocation would occur.)

Other features for Java release 1.5 will perform certain kinds
of autoboxing, which also violates the design principle.  This fact
will make it easier to argue for restoring full-blown support
for closures in the future.

It would be really nice to know more about what goes on inside Sun with respect to the Java language. I suppose we might just end up with endless blog-debate about what did/didn’t end up in the language, and about why such decisions were made.

Guy Steele wrote:
Please remember that the design of a programming language consists
not just in a laundry list of features, but also in making judicious
choices of what to *omit* and, more importantly, in establishing
design principles that are easy to understand.