实例化可以是具体类或接口类的Java类

我正在努力将一个大型代码库从一个API版本移植到另一个版本（特别是Hadoop CDH3到Hadoop CDH4）

在这些库的“升级”过程中，有人决定将常用的具体类（JobContext）更改为接口，并将其所有功能移动到子类（JobContextImpl）中。通常这是一个相当直截了当的提议。但是，我们仍然需要维护对旧版本库的支持，从而支持类作为具体的接口和接口

很明显，我们可以有两套不同的罐子，根据我们使用的hadoop版本，我们可以将它们换掉，但这会给我们带来很多不必要的头痛。我想创建一个可以同时运行两个hadoop版本的版本

当然，工厂模式会首先出现在您的脑海中，但问题是新版本中的实现类在以前的版本中不存在，因此代码一次只能针对一组库进行编译，并且只能针对一组库运行

接下来，我尝试使用groovyscript和一些巧妙的反射来检测类库的哪个版本在类路径中。我可以引用这些对象，但使用我没有编译的库中的一个实例，我会：

不兼容ClassChangeError:找到接口org.pain.MyContext，但应为类

编辑：

---

总之，我需要能够实例化一个可以是具体类或接口的类。我可以检测它是哪一个，如果它是一个接口，我知道实现在哪里，但如果是具体的，那么实现类就不存在。

没有办法让JVM忽略二进制不兼容；i、 e.同一类型的相互矛盾的定义

也许可以解决这个问题，但这会非常尴尬

您需要做的是：

• 从源代码中删除对

  JobContext

  类的所有直接和间接引用
• 将

  JobContext

  类型的所有变量替换为

  Object

• 使用使用

  Class.forName（…）

  获得的

  JobContext

  的

  Class

  替换对以

  JobContext

  为参数的方法和构造函数的所有调用，或使用反射方法或构造函数调用返回结果

简而言之，如果您可以去掉代码使用或依赖静态加载的

JobContext

的所有位置，那么您就不会得到该类的任何

不兼容的ClassChangeError

异常

---

---

老实说，我认为您最好只针对两个Hadoop API单独编译代码库。

谢谢您的输入。我倾向于同意。即使我可以实例化它们，我也还没有找到一种方法在运行时将其转换为适当的类型，以便将其传递回hadoop。当传递到其他库时，必须显式。。。