Anonymous inner classes aren't really closures in the more traditional sense, since they require that the captured variables be final; that makes them more rest

Anonymous inner classes aren't really closures in the more traditional sense, since they require that the captured variables be final; that makes them more restricted than closures generally are in other programming languages. That might not be a problem for Erlang given its write-once variables, but it is a problem for other languages. We've been working on generating JVM bytecode for our in-house language, which does support a less-restricted version of closures, and we work around that by wrapping closed variables in one-element arrays, though you have to do for both the initial declaration and on every reference to that variable, even outside the closure, which gets really annoying when the closed variable is something passed onto the stack as a function argument, and probably in other cases I'm not thinking about right now. It's definitely workable, it's just messy and incurs more overhead than is ideal.