闭包意味着完全类型安全的标准？答案

【问题标题】：closures mean fully type-safe criteria?闭包意味着完全类型安全的标准？
【发布时间】：2009-11-20 21:02:47
【问题描述】：

结合闭包 (FCM) 和泛型，是否有可能拥有完全类型安全的标准。

// The following works without a cast as Foo.id is a 'long' field.
List<Long> ids = session.createCriteria(Foo.class)
                        .setProjection(Foo#id)
                        .list();

// The following is a compilation error, as Foo.bar is defined as an int, and not a string
session.createCriteria(Foo.class)
       .addRestriction(Restrictions.eq(Foo#bar,"blah"))
       .list();

我已阅读 JPA 2.0 规范以了解类型安全标准。但还是有些欠缺。

此外，我只是在此处使用标准作为一般改进代码类型安全性的示例。我大量使用 java 的静态类型来让我更快地编写代码。但结果我时不时地被忽略输入的代码部分咬伤。例如 HQL 查询。

【问题讨论】：

让我直截了当...两天前宣布闭包将成为 Java 的一部分，您想知道这将如何影响 JPA 查询的创建吗？我认为社区中没有任何人在这种程度上解决了 FCM 式闭包的后果。

标签： java closures criteria type-safety java-7

【解决方案1】：

您描述的代码不使用闭包，而是使用字段文字 (method literals)。就像以前的 class literal 一样。这些可能有助于标准 API。类型安全查询接口的JPA 2 source code generation work-around 可以用它替换。如果它将成为 JDK7 的一部分。

【讨论】：

谢谢，我只是想再看看这个。 “使用闭包”是指 FCM 附带的字段文字。我当然希望 Sun 坚持这个提议，因为它提供的不仅仅是关闭桌子。

【解决方案2】：

正如 Thomas 所指出的，这并不严格要求闭包。目前这一切都悬而未决，因为没有人知道正在研究什么提案。目前尚不清楚 FCM 是否真的是该提案的基础，特别是考虑到 Stephen Colebourne 似乎和任何人一样对该公告感到惊讶。

很多人都在指出Neal Gafter's mysteriously-revised-more-or-less-right-as-the-Devoxx-presentation-announcing-closures-was-being-given spec 作为闭包可能采用何种形式的提示。请注意，修改后的提案看起来（在美学上）很像 FCM！

该规范确实包括您引用的引用类型（在上一行的“方法引用”下），当然 FCM 也有相同的。是的，这肯定会让你的建议成为可能。在阅读这方面，我的第一个想法是它会如何影响 JPA/Hibernate，和/或我们自己的抽象层，在这方面。您的标准中的类型安全、可重构的方法引用？是的。

【讨论】：

方法文字（有一些限制）并不难用记录器实现（参见easyMock）。字段文字更难（参见 JPA2）。没有理由为什么方法和文字现在不在 Java 中。甚至 javadoc 也有。