很多人因为用了“跨平台的语言"写没有写的出跨平台的程序而盲目的认为该语言的跨平台性是子虚乌有。

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

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

对于一段Java程序，要让它可以执行，得至少经过两个步骤，第一步，用Java编译器将源码编译成字节码;第二步，用Java解释器执行字节码。可见可见，Java程序并非像C程序那样直接执行，而是要有个启动器，也就是所谓的JVM(JavaVirtualMachine)来加载并执行。由此可见，Java跨平台的两个重要因素是：

1.有个能产生符合Java规范的字节码的编译器;

2.有个能解释上述符合Java规范的字节码的解释器。

换句话说，在任何操作系统上，只要存在JRE，就可以运行Java可执行体，而无所谓它来源于何处，只要”符合Java规范“就行。哈哈，到这里是不是有点乱，上面不是说Java的平台是JRE吗？难道JRE在不同的操作系统平台上还会变？是的，正是因为上述Java工具集是随操作系统的不同而不同的，我们才一再强调”符合Java规范的字节码“。因为Java编译器和Java解释器等一系列的工具集本身是依赖于操作系统的，只不过它们的输入和输出都符合统一的Java规范。如果上述两个条件换了其中任何一个，则很有可能使得Java不再跨平台。

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

误区一：Java语言是跨平台的，所以Java程序也是跨平台的

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

误区二：Java语言是跨平台的，所以Java程序是跨Java工具集的

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

误区三：Java语言是跨平台的，所以Java程序是跨Java应用服务器的

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