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中，如果方法签名的参数或返回类型中使用泛型类型，则可以执行泛型方法。在您的示例通用 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语言规范）在通用方法部分中说：

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

我没有检查代码（用两个编译器编译）。在更基础的语言规范中有很多奇怪的东西（好吧，检查数组声明......）。但是，我相信上面的设计有点“过度设计”，如果我正确地翻译了需求，则可以通过 工厂 模式或者如果您正在使用一些 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 的官方支持。我们也可以坚持这种类型的代码，并使用 Javac 7 和 target=1.6 进行我们的 Maven 构建，而在 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();
    }
}

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