1.2.6 结构中立

1.2.6 结构中立

编译器生成的目标文件格式是结构中立的——只要存在Java运行环境，编译后的代码就能在不同的CPU上运行。因为编译器生成的字节码指令与特定的计算机结构无关。这样的设计使得字节码指令既能够在任何机器上进行解释，也能够实时编译成本地机器码。

生成“虚拟机”代码并不是Java首创的。这项技术已被Lisp,SmallTalk,Pascal等使用了多年。
当然，解释虚拟机指令要比全速运行机器码慢一些。但是，虚拟机可以选择把最常被运行的字节码翻译成机器码——即JIT(just-in-time)编译。
Java虚拟机有另一个优势。因为它可以检查指令序列的行为，所以增加了安全性。

1.2.7 可移植性

与C/C++不同，Java说明文档中没有“依赖于实现”的方面。基本数据类型的大小，以及对基本数据类型施加算术运算得到的行为都是严格确定的。

例如，int在Java中始终是32位整数型。C/C++中，int可以是16位整数型，32位整型，或其他任何编译器厂商喜欢的长度。唯一的限制是：int至少要跟short等长，至多要与long等长。给数值类型以固定的长度解决了一个程序移植上的大麻烦。二进制数据按照固定的格式存储和传输，消除了关于字节顺序的混乱。字符串String使用标准的Unicode格式存储。

标准库作为系统的一部分，它定义了可移植的接口。例如，抽象Window类及其Windows、UNIX、和Macintosh版本的实现。

Window类这个例子可能选得不太合适。尝试的人都知道，要实现一个在Windows、Macintosh和十几种不同风格的UNIX上都能有很好表现的用户界面是难于上青天的。Java 1.0接受了这个挑战，捣鼓出来一个简单的工具包，这个工具包提供了在几种平台上共有的用户界面元素。遗憾的是，用这个库的时候，你得使上吃奶的劲头，才能捣鼓出一个在不同系统上都能勉强凑合的结果。从那之后，最初的用户界面工具包被替换了一次，又被替换了一次，平台间的移植性还是没有完全解决。
不过，对于其他不涉及用户界面的东西，Java库在平台非依赖性方面做得很不错。在我们写代码处理诸如文件、正则表达式、XML、日期和时间、数据库、网络连接、线程等问题的时候，完全不用担心底层的操作系统是什么。不仅你的程序变得可移植，而且Java API通常也比本地系统的API更好用。

1.2.8 解释型

Java解释器能够在任何移植了该解释器的机器上直接运行Java字节码。因为链接的过程更快速和简单。开发过程可以更高效，更具探索性。

这听起来很唬人。用过Lisp,Smalltalk,VB,Python,R或Scala的人都知道这里所谓的“高效和探索性”是什么东西。你尝试修改代码，立刻就可以看到结果。JDE并不注重这方面。