浅谈为什么java命令运行class文件出现异常

摘要

  相信每一个初学者学习Java时，刚开始练习编程Java都会写一个HelloWord程序，然后会按照书本上那样用命令行去编译，解释Java程序，或许当时你执行成功了；可是当你进一步学习更多的知识的时候，学到了用包命名空间来解决类名冲突后，你写的程序会更加完善健壮，而你此时还是利用初学时的方法去编译解释这个程序错误时，可能会遇到这个错误：Exception in thread “main” java.lang.NoClassDefFoundError:。
  今天呢我就浅谈一下对于这个异常的发生的原因和解决方案。我相信你看过之后会更加理解包在Java中的存在的意义！

举例

源程序如下：

package com.study.mengyi.access;
/**
 * 用于测试在dos下利用java命令行的形式运行程序
 * @ClassName TestDosRunning
 * @Description
 * @Author Meng Yi
 * @Date 2017年7月18日 上午11:01:37
 */
public class TestDosRunning {
    public static void main(String[] args){
        System.out.println("Code is running!");
    }
}

  当然你如果用IDE来运行程序，就不会出现开头出现的异常，因为开发工具已经帮你解决好了，这里先不细说，接下来我们在dos下面cd到源文件的路径下，用javac 编译这个源程序。

  如上图，若javac 命令后没有出现报错，说明我们的路径正确，编译成功，之后我们一般都会直接在当前目录下进行 java class文件（class文件为编译后的文件），例如本例 java TestDosRunning，然后当我们敲下这个命令运行后，发现会报错！

Exception in thread "main" java.lang.NoClassDefFoundError: TestDosRunning (wrong name: com/study/mengyi/access/TestDosRunning)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)

  上述异常的说的是：在主线程中存在一个异常：没有找到要运行的类文件（即class文件）。Wait，我就是在当前目录下进行运行的啊，文件名也对啊（注意大小写），怎么会找不到呢？百度一下吧，网上说的乱七八糟，密密麻麻的说了一堆了，你觉得如果是一个新手，他能认真看嘛，为什么不用自己话来解答这个问题呢？

分析

  既然报错说的是类文件没有找到，所以我们应该第一时间想到的是ClassPath类加载路径，该变量指示JVM在执行会在这个路径上面找到我们要运行的class文件，在之前呢，必须手动设置ClassPath，但是对于新手来说，设立这个无异是件麻烦的事情，所以Sun公司将Java2中JDk改造了更加聪明了一点，就是我们在设置好Java运行环境后，就不用再设置ClassPath变量，JDK会智能的找到类加载路径。而且默认的classpath会从当前目录中寻找class文件，这样说来，类加载的路径是对的。所以排除！
  难道我们的访问方式有问题？是的。首先看这个例子：

/**
 * 用于测试在dos下利用java命令行的形式运行程序
 * @ClassName TestDosRunning
 * @Description
 * @Author Meng Yi
 * @Date 2017年7月18日 上午11:01:37
 */
public class TestDosRunning {
    public static void main(String[] args){
        System.out.println("Code is running!");
    }
}

  What？这个怎么行？仔细对比与之前例子发现这个程序没有写包名，这也是为什么我刚学Java时，dos可以运行，而我用包之后怎么就不行了？
  我们先说下什么包？包是Java中为了解决命名冲突而设置的，包内含有一组类，这些类共同组成类库，包的命名方式采用域名倒着写，因为域名在全网是唯一的，所以这样我们创建的包名也就是唯一的，所以就不会存在类命名冲突问题。这样就导致了一个类的在JVM中必须是全类名，即包含前缀包名，这样解析器就可以正确的加载类，而不会出现歧义，所以我们在用java 执行命令时必须指定类的全类名。
  不写包名的话，意味着这是默认包，虚拟机会把所有的不写包名的类规整在一起组成默认包，所以不写包名情况的下，java TestDosRunning可以被解释器识别并执行。
  好了既然，我们理解了这样的方式，我们就用最开始的含包的程序检验一下是不是这个理，let’s go!

  what？我按全类名来运行了，怎么还不行啊？
  上面说到了包名采用了域名倒置的写法，这样的做法就是要做到有层次，虽然包名能唯一表示一个类，但是类文件始终都是要存储在操作系统中，而在操作系统是就是靠文件目录结构来解决命名冲突的，通过目录层次分划即可区分开不同的类，所以package名称被分解为机器上的一个目录。
  Java解析器的运行过程就是：首先，从classpath环境变量中类的各个存放路径，它们都为class文件的根目录。从根目录开始，解释器根据类的包名将转换成路径，比如com.study.mengyi.access;会被转换成根目录/com/study/mengyi/access，最后从access中读取到要加载的类文件。

方式一

  所以上面我们直接在D:\JavaLearning\ThinkInJava\src\com\study\mengyi\access目录下进行java com.study.mengyi.access.TestDosRunning，解析器会在access中寻找/com/study/mengyi/access，然而并没有这个目录，所以我们来手动生成一个这样的目录结构并把class文件复制过来检验一下！
  最终class文件的路劲为：
D:\JavaLearning\ThinkInJava\src\com\study\mengyi\access\com\study\mengyi\access

  运行成功！果然是这样，是不是一下子就对这个问题有更深的理解了？这样手动生成目录太累，所以我们可以在编译的时候这样javac -d . TestDosRunning.java 编译的同时为我们生成的这样的目录结构。

方式二

  既然解释器会找这样的目录结构，我们何不利用现成的，即我们可以回退到com父目录，在这里直接java com.study.mengyi.access.TestDosRunning，这时当前目录为：D:\JavaLearning\ThinkInJava\src

  经检验确实可以这样！

总结

  在java中类的唯一性靠包名命名空间来得到保证，这样在运行某个类必须冠以全类名的形式并对应好相应的目录结构，这样程序才可以正常运行。java的域名方式表示包名和包名对应操作系统的文件目录结构真是妙哉！美哉！