java 枚举 扩展_Java枚举类型增强，提供更强的类型支持详解

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

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

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

public enum Key {

HOST,

PORT,

SCORE

}

public interface PropertiesStore {

public void put(Key key, T value);

public T get(Key key);

}

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

put(PORT, “not a number”); // error, type mismatch: PORT is Key

// “not a number” is String

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

public enum Key {

HOST,

PORT,

SCORE {

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$RED、Colour$GREEN和Colour$BLUE。

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

var s = Key.SCORE; // type of s derived as Key$SCORE

s.normalise(8.29); // method normalise can be accessed

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

转载请注明来源网站:www.itxm.cn谢谢！

分享到：