最初的Lambda语法饱受诟病，但实际上，问题的严重性远不止纯粹的语法那么简单（毕竟，语法只不过是个外表而已）。其中一个主要的问题是Java并没有对函数类型提供直接的支持，这给Java类型系统带来了一些问题（函数数组可能引起异常泄漏）。无论能否克服这些问题（或者说在给定的JDK 7延期发布的时间内）,Lambda都不会再涉及函数类型了。
我们可以采用适配的方式简化内部类的编写过程。这些类叫做SAM（即Single Abstract Method）类。它代表了Java语言中抽象类与接口的一个重要子集，仅包含一个抽象方法。比如说，Runnable接口的run()方法、Comparator接口的compare()方法等（只包含一个抽象方法的抽象类也是可以的，比如Eclipse的org.eclipse.core.runtime.jobs.Job）。
目前进行中的规范表明下面两种表达方式是等价的：
Collections.sort(list,new Comparator() {
public int compare(Object o1, Object o2) {
return(o1.toString().length() - o2.toString().length());
}
}
// is the same as
Collections.sort(list,
{ Object o1, Object o2 -> o1.toString().length() - o2.toString().length() }
);
不得不说的是，Lambda语法依然处于提案阶段，未来可能会发生变化，但基本想法是在Lambda项目的帮助下，我们可以更加简洁的方式编写内部类，从而抛弃现在所用的匿名类方式。另外，Lambda会保持与内部类一样的表现力，可以从局部堆中获取状态（但堆是否要保持可变的状态依然是人们争论的热门话题）。然而，语言本身的一些变化（比如说可以高效获取final变量）以及类型与方法/异常推断的能力使得Lambda要比相应的匿名类更加简洁。
之所以采取这种方式，一个原因就是可以不必修改现有的类（主要是 java.util包中的集合类）。假如使用了函数类型方式，那么就必须得修改集合类以适应Lambda，或者是在JDK 7中放弃对Lambda的支持。其他程序库可能比较灵活，但整个Java类库并非这么容易修改，这也解释了为什么要采取其他方式。
还可以使用方法引用来代替SAMbda。如下代码所示：
public class Comparisons {
public static int compareLength(Object o1, Object o2) {
return(o1.toString().length() - o2.toString().length());
}
public static int compareHash(Object o1, Object o2) {
return(o1.hashCode() - o2.hashCode());
}
}
// examples
Collections.sort(list,#Comparisons.compareLength);
Collections.sort(list,#Comparisons.compareHash);
#代表方法句柄，类似于java.lang.reflect.Method。然而，与Method不同的是，他们是在编译期（而非运行期）确定的，JVM的JIT可以自动内联方法引用。这么做还具有其他优化效果，比如说针对给定的SAM类型，可以单独创建一个类表示代理的方法句柄而不必在使用时创建新的匿名类。
最后，还是存在一些有争议的问题。目前规范的最初草案禁止使用break和continue，但后来澄清说这么做的目的是为了防止跳出SAMBda而进入到封闭的范围内。另外一个主要的变化是return变成隐式的了，不允许在Lambda内部使用；但替代的关键字yield（不要与Thread.yield()混为一谈）与内部类中的return具有相同的语义。表面上来看，这么做可以实现在方法调用后，使用Lambda触发方法中的return的效果（即所谓的“long return”）。未来在语法上也会有一些变化，可以在Lambda中使用return，这需要使用新的关键字（或是关键字组合，比如long return）。其他相似之处还有使用this引用封闭的SAM实例，使用Outer.this引用封闭类的实例。
虽说使用Lambda替换SAM这个决定不如项目最初的提案那样雄心勃勃，但还是有不少优势的：实现简单、无需修改现有的集合类、能够很快派上用场（不管使用何种方式，只要增加函数类型就需要修改集合类）。未来，还可以使用相同的Lambda语法创建函数引用，但其目标是今后发布的JDK版本。
