系统：win10

JDK版本：11

单个.java文件的构建

这个就简单得一批了，一般java教程都会讲，这里展示一下流程：

新建一个java文件：

编辑这个文件

编译这个.java文件：

查看文件夹：

运行主函数：

把文件夹中Dog.class的文件名改成Cat.class：

执行java Dog命令：

做到这里你应该清楚以下几点：

1. 工程目录为demoPro
2. cmd当前处于demoPro文件夹下
3. Single.java文件中有且仅有Dog一个类
4. javac Single.java会在当前文件夹下生成Dog.class文件
5. java有一个惯例，就是一个.java文件代表一个类
6. 所以编译的时候，JDK会认为你这个Single.java起代表性作用的类是Dog，因此生成的.class文件的文件名为Dog.class，而不叫Single.class
7. 而你使用java Dog命令的时候，java实际上也会去找Dog.class这个文件，而不会进入到每个.class文件内部去找是否有Dog这个类，因为它认为，xxx.class这个文件名的文件里一定有xxx这个类
8. 所以我们把Dog.class改成Cat.class，java就找不到Dog这个类了。
9. 当然，一般也没有人闲到去改.class文件的名字，哈哈

多个java源文件的构建

先不多说，在一个文件夹下，我们有两个源文件：

查看一下这两个文件：

他们两个都严正声明自己是包com.P1中的，虽然它俩都在同一个文件夹shit下，跟com、P1半毛钱关系都没有。。

另外，FriendshipGraph类中有main函数，而且要调用Person类。

打开cmd，进入这个“shit”文件夹。

编译这两个文件的指令是：javac .\FriendshipGraph.java .\Person.java -d .\bin

javac是指令，.\FriendshipGraph.java和.\Person.java其实是要编译的文件相对于cmd当前所在文件夹的相对路径，“.”表示当前目录。-d表示编译出的文件我们想放在那，按照“国际管理”，我们要指定项目根目录下的bin文件夹，因为cmd现在就处于项目根目录下，所以用.\bin就可以直接指定到bin目录了。

执行命令，我们可以看到生成了如下的目录结构

它居然直接在bin目录下生成了一个神奇的目录结构！我们的源文件不是随便堆在根目录里的吗？？聪明的同学应该已经想到了，这是根据.java文件中的packge语句生成的目录结构。

至于为什么要生成目录结构，这个应该去问java语言设计师。我们只能自己理解，比如说运行程序的时候要到各个包里去找.class文件，包怎么体现呢？就用这种文件夹的形式。

好了，那么该如何执行呢？说到执行，目前肯定是要执行FriendshipGraph类中的main函数了。那我们就要去找到FriendshipGraph.class的位置。

这里要提醒一点，在bin目录下生成的子目录结构，我们不应该看成是子目录，而应该看成整体，看成一个包，比如bin\com\P1\FriendshipGraph.class，我们应该理解为bin\com.P1.Friendship，也就是bin文件夹下，com.P1包中的，Friendship这个类，我们要顺应设计师设计出的“包”这种思想。

那么现在的情况就是：项目根目录为shit，shit下面有一个文件夹叫bin，里面放着我们编译出来的东西，具体是啥呢？是一些包，包里有一些类。有了这样的思考方式，我们运行java程序就不容易出错了。

执行的指令是：java -classpath .\bin com.P1.FriendshipGraph

java是指令，-classpath .\bin是指定：我们的类文件都在bin目录下，回想一下刚刚说的，只有bin是文件夹，其他的子文件夹我们都理解为java中抽象的概念“包”，那么classpath，既然说了是“path”、是路径，那当然只能指定到bin为止了！如果你指定-classpath .\bin\com\P1的话，这不就过头了么？这不就是把“包”当成目录了么？这就是不对的。

然后命令的最后一部分你应该也很清楚了，是com.P1.FriendshipGraph，而不是com\P1\FriendshipGraph.class，因为什么？因为我们指定的是【包中的类】，我们指定的是【有一个主函数的类，这个类在com.P1这个包中】，而不是某个实体的文件。

命令执行结果如下，你可能不知道FriendshipGraph的主函数干了什么，但是这里就且信我一回吧，这里运行成功了。

其实到这里你应该已经很清楚了：

1. .java源代码文件可以任意放置，只要在其中的package语句中指定自己是哪个包的，编译的时候就会在-d目标输出目录（通常我们给它起名为bin）中自动形成良好的结构。
2. 生成的bin目录下的子目录要理解为包，.class文件要理解为包中的类。java命令要向它指定包在哪、执行哪个类（中的main函数）

但还有一个坑要注意，如果你把某些命令行参数的位置写错了，就会出现奇怪的错误：

例如我把classpath的指定放在类指定的后面，java就找不到类了，这真是太蠢了，是吧！

原理部分结束了，接下来是有关项目管理的

在一个复杂的项目中，我们通常会有一个项目结构：

如下图：其中shit是项目根目录，src、com、P1都是自己手动建的，而且要和.java文件指定的包一致。src是source的缩写，我们用这个文件夹名字是在提示自己，我把所有源代码都放在这里了。

你可能已经看出来了，这不就是在模仿bin之后将要生成的那个目录结构吗？确实，我们把源文件按包放在文件夹里，这有助于我们管理源代码之间的关系。

当然，现在是看不出来有啥好处，因为两个源文件都在一个包里，其实放哪都无所谓。但是如果有多个包的话，这样管理，我们就可以不用打开文件看看package语句就可以知道哪些文件在哪些包里了，比如这个，图中打开的文件是DrawableTurtle.java，它文件里写着“我是P2.turtle包里的”，所以我们把它放在src\P2\turtle文件夹下：

那么这样的工程怎么编译呢？

其实跟上面多文件的没啥区别，我们换回简单的例子：

打开cmd，进入shit文件夹，编译语句为：javac .\src\com\P1\FriendshipGraph.java .\src\com\P1\Person.java -d bin

跟上面多文件的例子也没啥区别，就是指定文件的时候路径变长了，运行完了之后会在shit\bin目录下生成我们编译的包结构，也跟多文件的例子一样：

既然bin文件夹的结构、内容都跟之前的例子一模一样了，那运行主函数的指令当然也没有任何区别：

结语

你可能觉得这没啥用，但是作为一个程序员能把IDE那些笨重的东西扔掉难道不让你觉得自己像个轻功大侠吗？

后续我还会继续出：用脚本文件编译执行程序（代替IDE中的run configuration），带库文件在cmd中执行程序，在cmd中用junit测试程序。

当然，这些我还没学完呢，所以你要是着急的话，可以先学了，学完了来教我，我非常乐意给你的粉丝数加1哦！