Java跨平台性的理解

  Java是可以跨平台的编程语言，那我们首先得知道什么是平台，从开发人员或编程语言的角度来理解，”平台“就是指语言的运行时环境，比如Java的平台就是JRE(Java Runtime Environment)。是不是觉得很奇怪，难道平台不是指Windows、Linux这样的操作系统吗？没错，Windows和Linux也确实是平 台，但是这个平台对于Java来说太宽泛了，就象从来没有人说Java的平台是i386、arm一样。简单理解就是光有操作系统是无法运行Java程序 的。而JVM则包含在JRE里。

        如果某个语言对应的可执行体能够不作修改或者只做少量修改就能在其他平台运行，那么这个语言就是跨平台的。是的，允许做少量修改，但是这个过程一般是在程序员不知道的情况下进行的，通常这个任务由平台来完成。但是不管怎么说，这只跟可执行体有关，而不是源码。

        我们把CPU处理器与操作系统的整体叫平台。CPU大家都知道，如果计算机是人,那CPU就是人的大脑，它既负责思维运算，又负责身体各部件的命令控制。CPU的种类很多，除去我们熟知的Intel与AMD外，还有比如上面说到的SUN的Sparc,比如IBM的PowerPC等等，这些各个公司生产的CPU使用或相同或不同的指令集。指令集就是cpu中用来计算和控制计算机系统的一套指令的集合。指令集又分为精简指令集（RISC）与复杂指令集(CISC)，每种cpu都有其特定的指令集。开发程序，首先要知道该程序在什么CPU上运行,也就是要知道CPU所使用的指令集。

       下面说操作系统，操作系统是充当用户和计算机之间交互的界面软件，不同的操作系统支持不同的CPU，严格意义上说是不同的操作系统支持不同CPU的指令集。例如 windows和liunx都支持Intel和AMD的复杂指令集，但并不支持PowerPC所使用的精简指令集，而早期的MAC电脑使用的是PowerPC处理器，所以也就无法在MAC下直接安装windows,直到05年MAC改用了Intel的CPU,才使在MAC下安装windows成为可能。但问题来了，原来的MAC 操作系统也只支持PowerPC,在Intel上也不能安装，怎么办？所以苹果公司也得重写自己的MAC操作系统以支持这种变化。最后总结下，我们要知道，不同的操作系统支持不同的CPU指令集，现在的windows,liunx,mac,solaris都支持Intel与AMD的CPU指令集。要开发程序，首先应该确定：1，CPU类型，也就是指令集类型；2，操作系统；我们把这种软硬件的结合叫平台。也可以说“平台= CPU+OS”。又因为现在主流的操作系统都支持主流的CPU，所以有时也把操作系统称为平台。

         我们知道，只要是用标准C开发的程序，使用不同的编译器编译后的可执行文件是可以在对应平台运行的，比如windows可以使用VC编译，那编译后的exe文件就可以在windows下运行；liunx下可以使用GCC编译，生成的可执行文件就可以在Liunx上运行。使用特定编译器编译的程序只能在对应的平台运行，这里也可以说编译器是与平台相关的，编译后的文件也是与平台相关的。我们说的语言跨平台是编译后的文件跨平台，而不是源程序跨平台，如果是源程序，任何一门语言都是跨平台的语言了。

         语言根据执行方式的不同分类：第一是编译执行，如上文中说到的C，它把源程序由特定平台的编译器一次性编译为平台相关的机器码,它的优点是执行速度快，缺点是无法跨平台；第二是解释执行，如HTML,JavaScript，它使用特定的解释器，把代码一行行解释为机器码，类似于同声翻译，它的优点是可以跨平台，缺点是执行速度慢，暴露源程序；第三种是从Java开始引入的“中间码+虚拟机”的方式，它既整合了编译语言与解释语言的优点，同时如虚拟机又可以解决如垃圾回收，安全性检查等这些传统语言头疼的问题，所以其后微软的.NET平台也使用的这种方式。

        对于一段Java程序，要让它可以执行，得至少经过两个步骤，第一步，用Java编译器将源码编译成字节码;第二步，用Java解释器执行字节码。 可见可见，Java程序并非像C程序那样直接执行，而是要有个启动器，也就是所谓的JVM(Java Virtual Machine)来加载并执行。由此可见，Java跨平台的两个重要因素是：
 1.有个能产生符合Java规范的字节码的编译器;
 2.有个能解释上述符合Java规范的字节码的解释器。
      换句话说，在任何操作系统上，只要存在JRE，就可以运行Java可执行体，而无所谓它来源于何处，只要”符合Java规范“就行。哈哈，到这里是不是有 点乱，上面不是说Java的平台是JRE吗？难道JRE在不同的操作系统平台上还会变？是的，正是因为上述Java工具集是随操作系统的不同而不同的，我 们才一再强调”符合Java规范的字节码“。因为Java编译器和Java解释器等一系列的工具集本身是依赖于操作系统的，只不过它们的输入和输出都符合 统一的Java规范。如果上述两个条件换了其中任何一个，则很有可能使得Java不再跨平台。

 

        除了以上两点，还有第三个因素，Java针对平台设计的库，也就是所谓的Jar包，这些jar包虽然大部分都是Java编写的，但是还是有不少地方是针对平台独特设计的，比如不同操作系统之间路径的表示，从这个角度讲，平台移植后的Java字节码已经被解释器改变了。

        同一个.class文件在不同的虚拟机会得到不同的机器指令（Windows和Linux的机器指令不同），但是最终执行的结果却是相同的

        误区一：Java语言是跨平台的，所以Java程序也是跨平台的
        ”Java语言“和”Java程序“并非同一个概念，Java语言实际上只是一系列的规范，该规范为程序员规定了Java的语法和语义规则。Java程序 则是根据这些规范产生的可执行体。通常情况下，程序的需求或多或少都会关系到一些操作系统之间的差异，比如，Windws的文件系统是多根的，Unix的 文件系统则是单根的;再比如，Java连接数据库的程序中，用到了与平台相关的ODBC，此时当程序拿到其他平台上去难免会出错。前面说了，Java工具 集是依赖于操作系统的，也就是说它们不能改变操作系统之间的差异，这就是JNI(Java Native Invoke)存在的原因之一。当一个程序使用了某个操作系统的特性并且移植后的操作系统没有此特性时，虽然它们能被该平台执行，但是还是会运行出错。

        误区二：Java语言是跨平台的，所以Java程序是跨Java工具集的
        从上面的说明可以看出，Java语言跨平台的本质是因为Java工具集遵循同一套规范。规范是个抽象的概念，那自然需要对应着一种实现，目前常见的有三种 实现，即Sun的官方实现;IBM的实现;GNU的实现。很有可能一套工具集对应与一套实现，使得不同实现之间并不通用，况且，每套实现在满足规范后还可 能增加自己的特性，比如，GNU可以直接将java源码、字节码、jar包等编译成本地可执行体。当然它们对源码规范的实现都是一样的，但是也并不保证这 些实现一定不会出现不同。因此对于给定的一套工具集，Java语言才是跨平台的，其他工具集则允许不是。

        误区三：Java语言是跨平台的，所以Java程序是跨Java应用服务器的
        在一套给定的工具集上，Java应用服务器做为JavaEE的容器，从本质上来说是JavaEE规范的实现，这样结合误区二就很容易理解了。不过还是要说一点，误区三其实根本就不该有，因为原因和结果本就不是一个层次的东西。