写点什么

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

  • 2017-01-12
  • 本文字数:1564 字

    阅读完需:约 5 分钟

最新的 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<T> {
HOST<String>,
PORT<Integer>,
SCORE<Double>
}
public interface PropertiesStore {
public <T> void put(Key<T> key, T value);
public <T> T get(Key<T> key);
}

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

复制代码
put(PORT, “not a number”); // error, type mismatch: PORT is Key<Integer>
// “not a number” is String

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

复制代码
public enum Key<T> {
HOST<String>,
PORT<Integer>,
SCORE<Double> {
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

2017-01-12 18:005446
用户头像

发布了 218 篇内容, 共 79.4 次阅读, 收获喜欢 76 次。

关注

评论

发布
暂无评论
发现更多内容

dnsmasq-域名访问及解析缓存

一周思进

【ARTS打卡】Week02

Rex

人人都是产品经理

二鱼先生

产品经理 个人品牌 职场成长 产品思维

极客时间-架构师培训-1期作业

Damon

架构师训练营第一周学习总结

刘志刚

架构方法学习总结

飞雪

架构师训练营-每周学习总结1

水边

极客大学架构师训练营

Flink源码分析之FlinkConsumer是如何保证一个partition对应一个thread的

shengjk1

flink flink 消费 kafka 实时计算 flink源码分析

程序员陪娃系列——数学启蒙趣事

孙苏勇

程序员 陪伴

程序员的晚餐 | 6 月 7 日 豆腐年糕

清远

美食

架构师训练营-命题作业1

水边

极客大学架构师训练营

食堂就餐卡系统设计

饶军

架构师训练营第一周作业

芒夏

极客大学架构师训练营

ARTS-WEEK2

一周思进

ARTS 打卡计划

Flink源码分析之Flink是如何kafka读取数据的

shengjk1

flink flink 消费 kafka flink源码分析 flink消费kafka源码解析

Flink源码分析之Flink 自定义source、sink 是如何起作用的

shengjk1

flink flink源码 flink源码分析 flink自定义source flink自定义sink

每周学习总结-架构师培训一期

Damon

SpringBatch系列之并发并行能力

稻草鸟人

Spring Boot SpringBatch 批量

食堂就餐卡管理系统

孙志平

食堂就餐卡系统设计

飞雪

Flink源码分析之-如何保存 offset

shengjk1

愚蠢写作术(3):如何把读者带入迷宫深处

史方远

学习 读书笔记 个人成长 写作

因为 MongoDB 没入门,我丢了一份实习工作

沉默王二

mongodb

不可不知的 7 个 JDK 命令

武培轩

Java 程序员 jdk 后端 JVM

Flink源码分析之Flink startupMode是如何起作用的

shengjk1

flink flink 消费 kafak 实时计算 flink源码 flink源码分析

ARTS打卡 week 2

猫吃小怪兽

ARTS 打卡计划

SpringBoot基本特性以及自动化配置-SPI机制

攀岩飞鱼

Java 微服务 Spring Boot SpringCloud

食堂就餐卡系统设计

刘志刚

Element-UI实战系列:Tree组件的几种使用场景

码上生长

vue.js 大前端 Elemen

架构师训练营第一周作业

小树林

LeetCode 769. Max Chunks To Make Sorted

liu_liu

LeetCode

Java枚举增强,提供更强的类型支持_Java_Abraham Marín Pérez_InfoQ精选文章