At a bytecode level, everything including and above assembler is syntactic sugar. I don't think there's any theoretical reason for the bytecode or the bytecode

At a bytecode level, everything including and above assembler is syntactic sugar. I don't think there's any theoretical reason for the bytecode or the bytecode assembler language to need to change. Just like there's no reason lisp and c can't both be compiled to IA32 bytecode, even though lisp has lambdas and c does not. Rather the issue is going to be at the compilation stage, where support for anonymous methods will need to be added. From my limited knowledge of compilers two ways it could be done are: * just give the lambda methods a namespace that is unique from the namespace programmers have access to (eg a variable with a space or a tab in its name). Now lambdas will be handled like regular named methods, but the namespace for them will be invisible to the programmer, and the compiler will be modified to have two method namespaces/an expanded namespace for functions. * Make all methods lambdas and then bind method variables to the lambda methods similar to how atomic/primitive (eg integer, float, chars) and other non-atomic/reference (objects, arrays) variables are bound to their anonymous objects. This is similar to how anonymous objects are handled. An anonymous object is what's returned by constructors, which are then bound to some variable. In this case the compiler needs to support methods that aren't bound to a variable. That said, it's entirely possible that making changes to the bytecode and the jvm will allow for faster running code, but those changes wouldn't be required out of some theoretical necessity for supporting lambdas.