OK，这将是我第三次打死马。
但是，这个问题与我前面两个关于闭包/委托(delegate)的问题不同，前两个问题询问委托(delegate)的计划以及闭包的预计规范和实现。
这个问题是关于 - 为什么 Java 社区努力定义 3 种不同类型的闭包，而我们可以简单地从我们亲爱的友好邻居 - 微软那里窃取委托(delegate)锁、库存和桶的整个概念。
我很想跳入两个非技术性的结论:
- Java 社区应该保持自豪感，以付出艰辛的努力为代价，不要屈服于借用任何微软的概念或以其他方式证明微软的才华。
- Delegates 是 Microsoft 的一项专利技术。
好吧，除了以上两种可能，
Q1。三种(或更多)闭包形式将解决的 .NET 样式委托(delegate)中是否存在任何弱点或不足？
Q2。我在 Java 和 C# 之间转换时问这个问题，这让我很感兴趣，因为 C# 委托(delegate)完全符合我的需要。是否有可以在 C# 委托(delegate)中当前不可用的闭包中实现的功能？如果是的话，它们是什么，因为除了 C# 委托(delegate)已经充分提供给我的，我看不出我需要什么？
Q3。我知道在 Java 中实现闭包/委托(delegate)的一个问题是减少语言的正交性，其中公开了不止一种方法来执行特定任务。为了确保 Java 保持其正交性级别而避免委托(delegate)而花费级别卷积和时间是否值得？在关系设计中，我们知道通过经常仅充分满足第二范式来打破正交性是可取的。为什么 java 不能为了简单起见而减少正交性和 OO 性？
Q4。 JVM 的体系结构在技术上受限于实现 .NET 风格的委托(delegate)。如果这个原因是(虚拟语气以强调不太可能)为真，那么为什么三个闭包提议不能隐藏在一个简单的委托(delegate)关键字或注释后面:如果我们不喜欢使用@delegate，我们可以使用@method。我看不出委托(delegate)声明格式比三个闭包提案更复杂。
最佳答案
你的问题很讽刺。您想知道为什么 Java 社区正在为添加闭包的三种不同提议而苦苦挣扎，而您建议的解决方案是添加第四种选择吗？
但要回答你的问题:
合适的讨论论坛是 openjdk 项目 lambda 的邮件列表。这里不是建议可能会影响这项工作的地方。
C# 和 Java 的类型系统明显不同，因此 C# 解决方案不能直接应用。例如，C# 具有声明位置差异(输入/输出)，而 java 具有使用位置差异(通配符)。 C# 中指定的 lambda 参数类型的推断不适用于 Java。
Java 的发展必须保持向后兼容，但添加 delegate 关键字将是一个重大变化。
C# 具有三种类型的委托(delegate)表达式:带有 delegate 关键字的旧委托(delegate)表达式、带有 =>{ 的语句 lambda 和表达式 lambda。如果C#语言团队要重来一次，我们肯定不会有这么多表格。为什么 Java 要采用 C# 的历史包袱？
因为 C# 泛型对基元进行操作，所以 Func<> 和 Action<> 委托(delegate)类型可以用作穷人的结构函数类型。但是在 Java 中，泛型被删除了，只对引用类型起作用，并且类型不能通过它们的数量来区分。因此，Java 必须有大量明确命名的“标准”函数类型才能获得相同的效果。那不会很漂亮。
总的来说，C# 解决方案不能适应 Java 中非常自然的解决方案。
关于c# - 为什么不用 .NET 风格的委托(delegate)而不是 Java 中的闭包？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2635013/