java和软件测试一样吗,你知道的Java和你不知道的Java

Java平台

通常有三种Java平台：Standard Edition(标准版，SE)、Enterprise Edition(企业版，EE)和Micro Edition(微型版)。每个平台都是一个包含某个语言版本、一组标准库和执行代码的虚拟机(见下文)的组合。EE是SE的超集，任何EE应用程序都可假定所有的SE库都存在。EE平台的语言使用与SE的一样。

由于小型设备(如：电话或机顶盒)的局限性，Java Micro Edition与另两个版本有很大区别。它并非SE的子集(像SE是EE的子集那样)，因为它的一些库只存在于Micro Edition中。而且，ME取消了一些语言特性，如float类型和Float类，这反映了它的运行平台的局限性。ME需要与SE和EE不同的工具，而且设备之间的巨大差异使ME领域代码的可移植性更加不现实，因此许多Java开发人员将ME视为异类。

Java虚拟机

在某种程度上，Java源代码需要成为平台自带的可执行代码。这个过程一般需要两个步骤：开发人员将源代码编译成Java字节码，然后Java虚拟机(JVM)将其转换为主机平台的本地代码。第二步最初是通过解释方式执行的：读取每条JVM指令，然后动态地将其转换为一条或多条本地指令。然后，在程序开始运行时，实时(just-in-time，JIT)编译器将所有的Java程序从JVM字节码转换为本地代码。如今，该过程有多种实现方式。Sun的HotSpot编译器在运行时解释并分析代码，编译并优化对程序的操作最为关键的那部分。IBM的JVM工作原理与此非常类似。这些方法避免了由于对整个程序进行实时编译所导致的启动时性能下降，随着时间的推移，性能将会恢复，因为关键的代码部分已被定位并优化。长时间运行的服务器进程很适合采用这种方法，但这对客户机应用程序不太适用。

就像基本类型一样，现在批评人士认为Java的这个两步编译周期是一种不成熟的优化方法。他们提出疑问：如果要等到运行时将Java字节码编译为本地代码，那么为何不采用解释Java源代码(而非Java字节码)的方式，从而为开发人员节省一个步骤？正如Tate在《Beyond Java》一书中所说的那样，“Java并不是最简单的语言。它对很短的迭代也不友好……其他语言允许轻松地应用更改，而无需麻烦的编译/部署周期。”

没有Java的JVM

实际上，Tate在寻找秉承Java成功表现的后继者的过程中抱有这样的理念：“下一个在商业上取得成功的语言应该拥有在JVM上运行的版本。这将有助于该语言克服许多障碍，不管是在策略上还是在技术上。”他指出，虚拟机方法可提供安全性(“如果能确保虚拟机的安全性，则要确保语言的安全性就容易得多了”)、可移植性、互操作性和可扩展性。由于JVM已有效地解决了这些问题，因此如果新语言可运行在已安装于数百万台计算机中的JVM上，那么它就不需要自己的虚拟机。

在许多方面，这种情况业已发生。用Java为脚本语言编写解释器可有效地将这些语言移植到JVM上，如：用于JavaScript的Rhino、用于Python的Jython或者用于Ruby的JRuby。

但也可以完全绕过Java语言，而直接进入JVM级别。已经有一些将C转换为JVM字节码的编译器，如商业工具Axiomatic Multi-Platform C，它提供了ANSI C的子集。而且，Java字节码处理工具(如ASM和Apache BCEL)的发展允许Java应用程序在运行时创建可执行的类。这些类不再是Java语言，而是一种用于JVM编程的有效汇编语言。

或许由于意识到了在JVM上运行非Java代码的需求，最近已提交了一项新的JSR(Java规范请求)，即“Supporting Dynamically Typed Languages on the Java Platform(在Java平台上支持动态类型化语言)”(JSR 292)，它指定了一种新的字节码，将使JVM更适用于运行不含静态类型信息的语言。

32/3<123>