Java 泛型的特殊用途：“hack”还是“提高生产力”？

Question

我们一直在简化代码中泛型的一些定义和使用。 现在我们得到一个有趣的案例，举个例子：

public class MyWeirdClass {

    public void entryPoint() {
        doSomethingWeird();
    }

    @SuppressWarnings( "unchecked" )
    private <T extends A & B> T getMyClass() {
        if ( System.currentTimeMillis() % 2 == 0 ) {
           return (T) new MyClass_1();
        } else {
           return (T) new MyClass_2();
        }
    }

    private <T extends A & B> void doSomethingWeird() {
        T obj = getMyClass();

        obj.methodFromA();
        obj.methodFromB();
    }

    static interface A {
        void methodFromA();
    }

    static interface B {
        void methodFromB();
    }

    static class MyClass_1 implements A, B {
        public void methodFromA() {};
        public void methodFromB() {};
    }

    static class MyClass_2 implements A, B {
        public void methodFromA() {};
        public void methodFromB() {};
    }
}

现在看一下 MyWeirdClass 中的方法 'doSeomthingWeird()： 此代码将使用 eclipse JDT 编译器正确编译，但是在使用 Oracle 编译器时会失败。由于 JDT 能够生成工作字节码，这意味着在 JVM 级别，这是有效的代码，并且“只有”Oracle 编译器不允许编译这些脏（！？）的东西。 我们知道 Oracle 的编译器不会接受调用 'T obj = getMyClass();'因为 T 不是真正存在的类型。但是，既然我们知道返回的对象实现了 A 和 B，为什么不允许呢？ （JDT 编译器和 JVM 会这样做）。 另请注意，由于泛型代码仅在私有方法内部使用，我们不希望在类级别公开它们，用泛型定义污染外部代码，我们不感兴趣（从类外部）。

教科书的解决方案是创建一个接口 AB 扩展 A,B 但是由于我们有大量的接口用于不同的组合并且来自不同的模块，因此为所有组合创建共享接口将显着增加“虚拟”接口的数量，最终使代码的可读性降低。理论上，为了覆盖所有情况，需要对不同的包装器接口进行多达 N 次排列。 “面向业务的工程师”（其他人称其为“懒惰的工程师”）解决方案是这样保留代码并开始仅使用 JDT 来编译代码。 编辑：这是 Oracle 的 Javac 6 中的一个错误，并且在 Oracle 的 Javac 7 上也可以正常工作

什么意思？采用这种“策略”有什么隐患吗？

---

为了避免讨论（对我来说）不相关的点： 我不是在问为什么上面的代码不能在 Oracle 的编译器上编译我知道原因，如果在使用其他编译器时可以完美运行，我不想在没有充分理由的情况下修改这种代码。 请专注于方法'doSomethingWeird()'的定义和用法（不给出具体类型）。 有没有一个很好的理由，为什么我们不应该只使用允许编写和编译此代码的 JDT 编译器并停止使用 Oracle 的编译器进行编译，Oracle 的编译器将不接受上面的代码？ （感谢输入）

编辑：上面的代码在 Oracle Javac 7 上编译正确，但在 Javac 6 上编译不正确。这是一个 Javac 6 错误。所以这意味着我们的代码没有任何问题，我们可以坚持下去。 问题已回答，我会在两天超时后将其标记为我自己的答案。 感谢大家的建设性反馈。

Answer 1

在java中，如果方法签名的Parameter或Return Type中使用了泛型类型，则可以执行泛型方法。在您的示例通用 doSomethingWeird 方法中，但从未在方法签名中使用它。 请参阅以下示例：

class MyWeirdClass
{
    public void entryPoint()
    {
        doSomethingWeird(new MyClass_1());
    }

    private <T extends A & B> T getMyClass()
    {
        if (System.currentTimeMillis() % 2 == 0)
        {
            return (T) new MyClass_1();
        }
        else
        {
            return (T) new MyClass_2();
        }
    }

    private <T extends A & B> void doSomethingWeird(T a)
    {
        T obj = getMyClass();

        obj.methodFromA();
        obj.methodFromB();
    }
}

这段代码运行良好。

JLS(Java Language Specification) 在 Generic Method 部分说：

Type parameters of generic methods need not be provided explicitly when a
generic method is invoked. Instead, they are almost always inferred as specified in
§15.12.2.7

当您在doSomethingWeird 方法签名中不使用T 时，通过此引用，您在调用时指定T 的原始类型（在entryPoint 方法中）？

Answer 2

我没有检查代码（用两个编译器编译）。在更基础的语言规范中有很多奇怪的东西（好吧，检查数组声明......）。但是，我相信上面的设计几乎没有“过度设计”，如果我正确地翻译了需求，则可以使用Factory 模式来实现所需的功能，或者如果您使用一些 IoC 框架（Spring？）然后查找方法注入可以为你施展魔法。我认为代码会更直观，更易于阅读和维护。

Answer 3

我认为原因不同。 “T obj = getMyClass();”行上的类型 T 不是真的是未知的——事实上，由于定义“T extends A & B”，它的擦除是A。这称为多重界限，适用于：“当使用多重界限时，界限中提到的第一个类型被用作类型变量的擦除。”

Answer 4

根据@MJM 的回答，我建议您更新代码如下。那么您的代码将不依赖于 JVM 的类型推断。

public void entryPoint() {
    doSomethingWeird(getMyClass());
}

private <T extends A & B> T getMyClass() {
    if (System.currentTimeMillis() % 2 == 0) {
        return (T)new MyClass_1();
    } else {
        return (T)new MyClass_2();
    }
}

private <T extends A & B> void doSomethingWeird(T t) {
    t.methodFromA();
    t.methodFromB();
}

Answer 5

我会再次创建你所谓的“虚拟”接口AB。

首先，我根本不觉得它是假的。有两个类具有相同的通用方法定义，并且在一个地方您需要使用其中之一，而不管它实际上是哪一个。这就是继承的确切用法。所以界面AB 非常适合这里。泛型在这里是错误的解决方案。泛型从来都不是用来实现继承的。

其次，定义接口将删除代码中的所有泛型内容，并使其更具可读性。实际上添加一个接口（或类）永远不会降低你的代码的可读性。否则，最好将所有代码放在一个类中。

Answer 6

这是 OpenJDK 人员对我的问题的回答：

这些故障是由于 JDK 6 编译器没有 正确实现类型推断。已经付出了很多努力 JDK 7 编译器为了摆脱所有这些问题（你的程序 在 JDK 7 中编译良好）。然而，其中一些推理改进 需要源不兼容的更改，这就是我们不能向后移植的原因 JDK 6 版本中的这些修复。

所以这对我们来说意味着：我们的代码绝对没有问题，并且得到了 Oracle 的官方支持。我们也可以坚持使用这种代码并在我们的 maven 构建中使用 target=1.6 的 Javac 7，而在 eclipse 中开发将保证我们不使用 Java 7 API：D yaaahyyy！！！

Answer 7

您的方法是有问题的，因为未经检查的强制转换牺牲了运行时类型的安全性。考虑这个例子：

interface A {
    void methodFromA();
}

interface B {
    void methodFromB();
}

class C implements A { // but not B!
    @Override public void methodFromA() {
        // do something
    }
}

class D implements A, B {
    @Override
    public void methodFromA() {
        // TODO implement

    }
    @Override
    public void methodFromB() {
        // do something
    }
}

class Factory {
    @SuppressWarnings( "unchecked" )
    public static <T extends A & B> T getMyClass() {
        if ( System.currentTimeMillis() % 2 == 0 ) {
           return (T) new C();
        } else {
           return (T) new D();
        }
    }
}

public class Innocent {
    public static <T extends A & B> void main(String[] args) {
        T t = Factory.getMyClass();

        // Sometimes this line throws a ClassCastException
        // really weird, there isn't even a cast here!
        //                         The maintenance programmer
        t.methodFromB();
    }
}

（您可能需要多次运行该程序才能了解维护程序员的困惑。）

是的，在这个简单的程序中，错误是相当明显的，但是如果对象在程序的一半左右被传递，直到它的接口丢失怎么办？您将如何找出坏对象的来源？

如果这不能说服你，那又如何呢：

class NotQuiteInnocent {
    public static void main(String[] args) {
        // Sometimes this line throws a ClassCastException
        D d = Factory.getMyClass();
    }
}

消除几个接口声明真的值得吗？