郑州建网站十大,合肥高端网站建设设计公司,贴吧做网站,企业网站建设规划ppt我最近偶然发现了JDK API的一个非常有趣的警告#xff0c;即Class.getConstructors()方法。 它的方法签名是这样的#xff1a; Constructor?[] getConstructors()有趣的是#xff0c; Class.getConstructor(Class...)返回一个ConstructorT #xff0c;并… 我最近偶然发现了JDK API的一个非常有趣的警告即Class.getConstructors()方法。 它的方法签名是这样的 Constructor?[] getConstructors() 有趣的是 Class.getConstructor(Class...)返回一个ConstructorT 并保持了T ConstructorT getConstructor(Class?... parameterTypes) 为什么会有区别即为什么第一个方法不返回ConstructorT[] 让我们考虑一下Javadoc 请注意尽管此方法返回一个Constructor T对象的数组也就是此类的构造函数的数组但此方法的返回类型为Constructor []而不是Constructor T []。预期。 这种信息量较少的返回类型是必需的因为从此方法返回后可以修改该数组以容纳不同类的Constructor对象这将违反Constructor T []的类型保证。 这是一个艰难的过程。 从历史上看这是怎么发生的 Java 1.0 / Oak数组 在Java 1.0 Oak编程语言的直接继承者中已经引入了数组。 实际上它们是在Java 1.2中引入的collections API之前引入的。 数组遭受着我们今天所知道的所有问题包括它们的协变这在运行时导致了很多问题这些问题在编译时无法检查 Object[] objects new String[1];
objects[0] Integer.valueOf(1); // Ouch Java 1.1反射API 缺少“不错的” collection API Class.getConstructors()方法唯一可能的返回类型是Constructor[] 。 当时的合理决定。 当然您可能会犯上述相同的错误 Object[] objects String.class.getConstructors();
objects[0] Integer.valueOf(1); // Ouch 但是除了上述内容之外您还可以正确地编写以下代码 Constructor[] constructors String.class.getConstructors();
constructors[0] Object.class.getConstructor();// Muahahahahahahaha Java 1.2Collections API Java从很早的时候就一直向后兼容甚至从Oak开始。 到目前为止在这个Stack Overflow问题中关于Oak的一些向后兼容性已泄漏到Java中这是一个非常有趣的历史研究。 虽然使用集合来设计反射API是很自然的但是现在已经为时已晚。 更好的解决方案可能是 List getConstructors() 但是请注意我们还没有泛型因此数组实际传达的类型信息比集合多。 Java 1.5泛型 在Java 5中 Constructor[] getConstructors() 至 Constructor?[] getConstructors() 已经出于上述原因进行了处理。 现在使用集合的替代API肯定会更好 ListConstructorT getConstructors() 但是船开了。 Java丑陋的疣 Java充满了这些小警告。 它们都记录在Javadocs中并且经常在Stack Overflow中记录。 就在昨天我们在Map和ConcurrentHashMap记录了与全新API相关的新警告 。 “管理权发人深省”关于所有这些警告以及Brian Goetz维护这些警告的难易程度的很好演讲可以在这里看到 演讲摘要 语言设计师谈论他们正在设计的语言时 翻译自: https://www.javacodegeeks.com/2015/03/the-java-legacy-is-constantly-growing.html
