我可以使用在 Java 7 中编译的 jar 作为为与 Java 6 兼容而编译的项目中的依赖项吗？我没有依赖项的源代码。我将编译后的 jar 作为 Maven 依赖项。
我可以使用在 Java 7 中编译的 jar 作为为与 Java 6 兼容而编译的项目中的依赖项吗？
让我们取消选择这个：
您有一个已编译的项目，可以在 Java 6 JRE 上运行。 （假设您在该项目中仅使用 Java 6 API。）该项目的 .class 文件必须的类文件格式主要版本小于或等于 50 ...否则 Java 6 JRE 将无法加载它们。
然后你就有了一个“在 Java 7 中编译”的依赖项。 这可能意味着以下两件事之一：
它可以使用 Java 7 工具链进行编译，但目标版本是 Java 6。
它可以使用 Java 7 的 Java 7 工具链进行编译。
在上述两种子情况下，如果您在 Java 7 JRE1 上运行项目，您应该能够在 Java 6 项目中使用依赖项。 Java 7 JRE 可以加载并运行为 Java 6 编译的类文件。在其中一种情况下，您将加载具有两个（或更多）类版本号的类。 不过没关系。
另一方面，如果您尝试在 Java 6 JRE 上运行代码，那么：
子情况 1 将起作用 前提是Java 7 依赖项不使用任何 Java 7（或更高版本）API；即它仅使用 Java 6 或更早版本中存在的 Java 标准类、方法等。
子情况 2 不起作用。 Java 6 JRE 将无法加载依赖项。 事实上，如果依赖项是静态的（即项目源代码对依赖项的 API 具有编译时依赖项），则项目代码将无法构建...因为 Java 6 编译器应该拒绝读取依赖项的较新版本类文件.
最建议的方法是将您的项目和执行平台迁移到 Java 7。或者更好的是迁移到 Java 8 或 Java 11，因为 Java 7 已停产
如果你做不到这一点，下一个最好的办法就是避免使用 Java 7 依赖项......直到你可以升级。
如果您的客户坚持要求您继续支持 Java 6，那么他们就会阻碍您推进产品线的能力和/或花费您额外的精力来支持他们。 他们应该为此支付额外费用2。
如果您因内部原因决定避免升级 Java 平台，则此决定正在积累技术债务……从长远来看，您的组织将需要“偿还”该债务。
1 - ....或 JDK。 JDK 相当于用于运行代码的 JRE。
2 - ...或不再提供支持。
在您的情况下，您实际上会问Java 6和Java 7之间是否存在前向兼容性。一般来说，Java不支持前向兼容性，因为1.7 JVM无法运行用1.6编译的代码。发生这种情况主要是因为旧版本（1.6）无法识别 1.7 版本编译的 Java 字节码。