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.