使用JMock 1.37+JDK1.7时出现类加载器版本兼容问题咨询

首先得明确，UnsupportedClassVersionError: 52.0这个错误直接说明：你用JDK 1.7的JVM去加载了一个用JDK 1.8编译的类——这里就是com.sun.tools.attach.spi.AttachProvider，因为JDK版本对应的字节码版本是固定的：1.7对应51.0，1.8对应52.0。

至于为啥加载的是JDK 1.8的tools.jar里的类，而不是jmock.jar中的同名类，主要有两个核心原因：

1. 类加载的双亲委派规则：Java的类加载器是按双亲委派模型工作的，系统类加载器会先委托给上层的扩展类加载器/启动类加载器，优先从JDK的核心库（包括tools.jar）里加载类。只有当上层加载器找不到这个类时，才会轮到应用类加载器去加载jmock.jar里的类。所以只要JDK的tools.jar里存在这个类，就会被优先加载。
2. 环境配置混入了JDK 1.8的依赖：大概率是你的运行环境里不小心引入了JDK 1.8的tools.jar。比如JAVA_HOME配置错成了1.8，或者IDE的项目SDK虽然选了1.7，但classpath里偷偷加了1.8的tools.jar，又或者系统全局的classpath包含了这个高版本的jar包。

针对这个问题，咱们按优先级来处理：

• 先确认运行环境的JDK版本：打开终端/命令行，运行java -version和javac -version，确保输出都是1.7的版本。如果不是，修正JAVA_HOME环境变量，指向正确的JDK 1.7路径，同时更新系统的PATH变量，确保优先使用1.7的java命令。
• 清理classpath中的冲突依赖：
  • 如果是用IDE开发，检查项目的SDK设置（比如IntelliJ的Project Structure、Eclipse的Build Path），确认Module和Project的SDK都是JDK 1.7，并且依赖库中没有引入JDK 1.8的tools.jar。
  • 如果是用Maven/Gradle构建，检查依赖配置，有没有间接引入了高版本的tools相关依赖，或者插件配置里指定了错误的JDK版本。
• 调整类加载顺序（备选方案）：如果实在无法移除JDK 1.8的tools.jar依赖，可以考虑自定义类加载器，打破双亲委派模型，让应用类加载器优先从jmock.jar中加载com.sun.tools.attach.spi.AttachProvider类。不过这种方式比较复杂，容易引入其他类加载问题，只建议作为最后手段。
• 升级JMock版本：JMock 1.37确实比较老旧了，看看有没有兼容JDK 1.7的新版本（比如JMock 2.x的部分版本），升级后可能会修复这类兼容性问题，避免依赖冲突。

内容的提问来源于stack exchange，提问作者Zeyu