Java枚举增强,提供更强的类型支持

Java枚举即将获得增强,包括更好的泛型支持及为单个项目添加方法的能力。这将提升类型安全性并提供更丰富的功能,无需运行时更改。此外,枚举的泛型支持有望与Valhalla项目中原始类型泛型的改进相结合。

最新的JEP上显示,Java枚举将增强泛型支持,并能将方法添加到单个项目上去。这两个功能可以通过一次更改进行交付,原因是它们捆绑在了一起。更改仅仅会影响到Java编译器,因此不需要运行时更改。虽然没有目标版本,但可能会在Java 10中呈现更改。

\\

一开始这个更改没有得到很大的肯定,比如杰出的Java Champions Joshua Bloch就其实用性提出了质疑。然而,通过进一步的讨论和新用例的介绍帮助它逐步获得了支持。

\\
\

以防你没有看到我对@BrianGoetz的回应,我已经看到了JEP列出的介绍,我也撤回了我先前对这个变更的不看好观点。用例:https://t.co/O1tJO8oSCp
\——Joshua Bloch (@joshbloch) 2016年12月7日

\
\\

让我们一起通过JEP中举出的用例和一些其他讨论来总结一下这次变更给开发者带来了什么改变。Java Champion Lukas Eder提出了一个StackOverflow的问题,介绍了通过配置文件、web会话或类似类型安全的方式检索和设置属性的用例。带有泛型支持的枚举让我们可以指示一组可用的键和它们相关联的类型:

\\
\public enum Key\u0026lt;T\u0026gt; {\HOST\u0026lt;String\u0026gt;,\PORT\u0026lt;Integer\u0026gt;,\SCORE\u0026lt;Double\u0026gt;\}\\public interface PropertiesStore {\    public \u0026lt;T\u0026gt; void put(Key\u0026lt;T\u0026gt; key, T value);\    public \u0026lt;T\u0026gt; T get(Key\u0026lt;T\u0026gt; key);\}\
\\

现在,这些键可以安全地在属性存储中进行检索和存储,因为下面的表达式将无法编译:

\\
\put(PORT, “not a number”); // error, type mismatch: PORT is Key\u0026lt;Integer\u0026gt;\                           // “not a number” is String\
\\

另一方面,允许单个项目有自己的方法可以帮助定义只适用于某些属性的操作。根据JEP 301所述,上述定义可以扩展如下:

\\
\public enum Key\u0026lt;T\u0026gt; {\HOST\u0026lt;String\u0026gt;,\PORT\u0026lt;Integer\u0026gt;,\SCORE\u0026lt;Double\u0026gt; {\    double normalise(double x) {\        // score normalisation logic\        return result;\    }\}\}\
\\

根据当前的枚举,所有项目都有通用类型Key,这意味着方法normalise将不可见。但是在这项工作完成后,编译器将会保留这类型信息,这代表着以下的将为真:

\\
\SCORE.normalise(5.37); // compiles\HOST.normalise(5.37); // error: neither HOST nor Key have normalise\
\\

要实现这一点,需要改变计算各个枚举项目的静态类型的方式。正如读者可能知道的一样,枚举在Java 5中仅仅作为纯粹的语法上的甜头而添加:JVM对枚举没有任何特殊的处理,而是由编译器将枚举转换为带有静态对象的普通类,然后将其编译为字节码。抛开一切技术方面的问题,下面的枚举:

\\
\public enum Colour {\ RED, GREEN, BLUE\}\
\\

由编译器粗糙地进行了转换,如下(这不是一个非常准确的表达,但是足以解释清楚):

\\
\public class Colour extends Enum {\public static final Colour RED = new Colour();\public static final Colour GREEN = new Colour();\public static final Colour BLUE = new Colour();\\    private Colour() {}\}\
\\

由于所有项目的类型是Colour,任何项目特定的方法和类型信息都会丢失。JEP 301要做的是确定使用通用枚举类型不足以表示单个项目的情况,在这种情况下生产更多更具体的类型,如Colour$REDColour$GREENColour$BLUE

\\

增强的枚举甚至可以从JDK其他部分正在进行的工作中受益。一方面,局部变量类型推断可以让开发人员获得由编译器创建的更清晰的类型,即使这些类型的确切形式在编写代码的时候是未知的,这意味着上面的代码可能是以下这样的:

\\
\var s = Key.SCORE; // type of s derived as Key$SCORE\s.normalise(8.29); // method normalise can be accessed\
\\

另一方面,一些证据和用例都表示枚举中的泛型可能更加广泛地使用于原始类型,这是相当低效的(JVM必须为每个原始类型使用装盒后对应类型)。这可以通过Valhalla项目处理原始类型的泛型这个部分消除障碍,并使其可用于大规模使用。

\\

查看英文原文Java Enums to Be Enhanced with Sharper Type Support

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值