Linux运行Java程序报Classpath错误 Windows访问同目录可正常运行

这个问题和Java小版本差异没有关系，核心原因是Linux环境下classpath中的java-cup-11a.jar无法被JVM正常读取，两次不同的报错完全是JDK 8的classpath加载顺序机制导致的，和你代码、jar包内部的类文件结构无关。

• JDK 8的类加载逻辑是严格按照-cp参数里从左到右的顺序逐个扫描jar包/路径，只要扫描过程中碰到一个无法正常解析的jar（压缩包损坏、无读权限、不是合法的zip格式），就会直接终止整个classpath的扫描流程，不会继续读取后面的jar条目。
• 对应你第一次执行的命令，classpath顺序是jflex.jar:java-cup-11a.jar:myparser.jar：JVM顺利加载完jflex.jar后，碰到无法读取的java-cup-11a.jar直接中断扫描，根本没加载到后面的myparser.jar，所以报“找不到main.Parser”，和你myparser.jar里是否存在Parser.class没有关系。
• 你调整顺序把myparser.jar放到最前面之后，classpath顺序变成myparser.jar:jflex.jar:java-cup-11a.jar：JVM先加载myparser.jar顺利找到了main.Parser类，但是Parser类依赖的java_cup/runtime/Scanner类在前面两个jar里都不存在，扫到后面无法读取的java-cup-11a.jar时加载失败，就抛出NoClassDefFoundError，连带触发JNI错误提示。

至于Windows端通过Samba访问同目录能正常运行，是因为Samba共享默认会重映射Linux文件权限，Windows端访问使用的Samba账号对该jar有正常读权限；且Windows下的HotSpot虚拟机处理classpath异常条目的逻辑和Linux下有差异，遇到无法读取的jar会跳过而不是直接终止整个扫描流程，所以能正常加载所有类。

你可以按顺序排查两个最高发的原因：

1. jar包传输损坏：从Windows往Linux复制jar时，如果用的是WinSCP、rz/sz、FTP这类工具，默认开启的文本传输模式会把二进制格式的jar包误判为文本文件，自动做换行符转换，破坏zip压缩包结构。直接在Linux下执行unzip -t java-cup-11a.jar校验压缩包完整性，如果报压缩包损坏，重新用二进制传输模式把这个jar重新传一遍即可。
2. 文件权限配置错误：如果压缩包校验没问题，执行ls -l java-cup-11a.jar查看文件权限——如果是用root账号复制的文件，默认权限通常是600，普通用户没有读权限，JVM自然无法加载。执行chmod a+r java-cup-11a.jar给所有用户加上读权限就能解决。

注：Linux下classpath用冒号:做分隔符是完全正确的，不需要怀疑分隔符配置问题。

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