我一直都怀疑被那些自以为博学的人不停讨论的最热门的话题Java™ 。您可以用一分为二的观点来对待这些问题，最终你被迫相信 Java 将带来世界和平并能偿还美国的国债或者它完全是在浪费时间。我常常想涉足这些讨论，但我还是尽量避而不谈，直到我能够提供广博的观点。
 
    设想一下当我从圣诞节假期归来时发现我的下一个任务是需要学习 Java 时，我是多么的惊慌（或者应当说成是恐惧）。你能说“留心你想要得到的东西，因为你可能正在得到它”吗？但是，我很高兴的发现学习比我预计的要容易。Java 是面向对象的设计方法，作为一个长期在复杂凌乱的 C++ 世界挣扎的 C 程序员，经过多年的面向对象的编程，作为一种回报我发现确实学到了一些原理和技术。的确，我承认我是一个 OLE 热衷者（阅读过 Nigel Tompson 的系列文章的 MSDN 订阅者都会理解我的意思），至少在产品代码迁移方面如此。但是，渐渐的我离开了无序的行列，至少在考虑 Java 时是这样。 

    我的第一个决定——并且是一个正确的决定——避免了选择类似于《利用你五天刷牙的时间学会 Java》这样的书。如果你最近到过书店的计算机技术部分（如果你可以外出），会知道那里有许多 Java 书籍。为了缩小你的查找范围，你可以选择适合自己的书。因为我有丰富的 C 程序经验，我找到一些适用于 C 程序员学习 Java 的书。例如，找到一本David Flanagan 所著的《简单的Java》（Java in a Nutshell 专用系统参考 1996年12月。ISBN：1556592183）。我还买了一本Addison-Wesley 出的《Java 系列》（参见http://www.awl.com/cp/javaseries/），这些书的确十分有用，但大部分都是编程参考。按照我自己通过实践进行学习的习惯，没过多久我就熟悉了。我开始时编写示例 Applet 程序，这在当时看来是很有用的，但很快我就认识到自己的知识很有限需要深入的学习。于是我开始浏览微软的Java 开发者 Web 站点和Sun MicroSystems 站点, 并且在下列站点也找到一些资料（这不是一个全面的列表）： 

    ·        Java 开发者 (最好的Java 编程疑问与解答)  
    ·        “Java Jolt”  (Web Developer.com 的指导专栏周刊)  
    ·        “Digital Espresso”  (Java 邮件列表摘要周刊和     Mentor Software Solutions 的新闻组活动)  
    ·        JavaWorld  (每月更新的关于 Java 社团的IDG 杂志)  
    ·        Javology  (每月更新的 Java 新闻和在线见解e-zine)  

    权威人士一些关于 Java 的观点让我感到鼓舞，我又回到原先起步阶段的 Applet 示例中，但是很快就又转移了视线，开始阅读 Sun Java 开发工具（JDK）的 Applet 示例源程序——可以从http://www.javasoft.com/nav/developer/index.html 下载。自然，当我开始看实现系统类的源代码时，觉得阅读示例源程序更有趣。 

    我的 Java 学习方法实践证明是比较成功的。由于正确的选择了适合自己 C 编程背景的启蒙书籍，我对 Java 有了相当充分深入的理解。学习的第二阶段通过到 Web 站点浏览，我又掌握了关于 Java 开发工具和相关问题的最新信息。经过阅读源代码，使我对 Java 的结构和实现有了本质的认识。
关于 Java 系列文章的第一篇将帮助每个 C 程序员解答“Java 可移植性的关键是什么？”这个问题。我将重点介绍设计方面使 Java 应用程序比其他技术在不同计算机平台之间有更好的可移植性的原因。但是，如果你想彻底理解这一切，Java 良好的可移植性内部的理论将是你学习的一个重点。我看到在 Java 新闻组中有大量的布告，反映出实际使用时不断出现的真正的问题。当然，人们也在抱怨 Java 的兼容性问题，我将从根本上解释这一问题。如果你认为该主题的文章有帮助，我将很感激你能告诉我（我的 e-mail 地址是michaele@microsoft.com ）。
 
    关于可移植性 

    提供创建高可移植性应用程序的便利是 Java 设计体系的核心要素。我的大部分编程经验是关于 C 语言的，八十年代当我开始自己的计算机游戏程序员生涯时，我就开始与可移植代码问题朝夕相伴。我所在的游戏公司常期支持几个不同的平台，包括Apple II、C64、Mac、Amiga、Atari ST 和 PC——使用游戏控制台，但未能成功。因此，“移植仪定”仿佛成了我的名字。当我在这些平台之间移植游戏时我学到了重要的一课：不存在完全可移植的代码；仅仅是可移植代码多和少的问题。我同时也掌握了一个可以产生尽可能多的可移植代码的方法。对我们来讲，这个方法包括尽可能多的用 C 语言编写代码，使用我们称为虚拟机的技术——我们移植到不同平台时所使用的基本库代码，该库充当运行我们的游戏程序所需的虚拟图形和用户输入库。因此，从我个人来之不易的创建可移植软件经验，我能证实 Java 通常使用可靠性好的技术来生成高可移植性的代码更容易。 

    总体上讲，我认为虚拟机方法将所有不同的平台平等对待来自一定的协定。为了解释这一点，让我讲述一个关于我所作的一个工程的故事，这是在我退出开发计算机游戏之前的最后一个工程。1988年，我所在的游戏公司面临一个艰难的决定，是否放下 Amiga 和Atari ST 对我们 PC 游戏的支持。那时我年轻而又天真，这个问题激怒了我。我们既然已经在 Amiga 上取得了初步的成功——我们怎么能考虑要放弃所创建的最好的游戏计算机？于是我日夜不停的工作了三个月来将我们的虚拟机移植到Amiga 和 Atari ST 平台上，并且我深信我可以将发布这些版本的问题化简为简单的重新编译问题。自然，我成功的实现了我们虚拟机的移植，甚至我还用了不到一周的时间演示了一个我们游戏的Amiga 和 Atari ST 版本。你能猜想到发生了什么吗？最终我们还是放弃了该平台。在1988年拥有 Amiga 的人中没有愿意仅仅为了 PC 游戏的移植而花钱的。如果他们想拥有一个 PC，他们会买一台 PC。相反，如果他们想要一个真正的游戏计算机，他们会买一台Amiga（这毕竟是1988年）。从中我接受了一个沉重的教训：虚拟机迫使你在编写软件时要在所需支持的结构上采用尽可能少的非公共标准。如实地支持不同结构中的不同特性需要额外的工作而且并不一定总是一个可行的选择。
 
    一个简要的澄清：我的同事程序员Paul Johns 审阅这篇文章时，他指出我的不恰当修辞比喻暗示：可移植代码与跨平台代码相同。可移植性意味着简单的重新编译一下软件就可以运行在另一个平台上，而跨平台（Java 辅助建立的定义）意味着只要编译一次代码就能够运行在任何地方（或者按照批评者所说的，编译一次就可以运行在任何它可以运行的地方）。我认为Paul 是正确的跨平台代码与可移植代码不同，但是你可以认为跨平台代码是所有可移植代码的根源。 

    是什么使得 Java 适合各种需求，使我们称它为跨平台可移植的呢？有三个主要的原因：结构上提供了源代码级的可移植性；应用程序编程模型被广泛而精确的描述（特别是作为语言的一个部分本身）；语言的几个要素使它们易于移植。
 
    虚拟机 

    我已经反复读到Java 是一个解释型编程语言。但是，这并不是严格正确的；更准确的讲 Java 语言通常（不总是）编译成字节代码，而字节代码有时（但不总是）被解释。因此， Java 源代码并不直接被翻译为特定计算机所特有的低级机器指令。但是等一下——当我修补 Java Applet 示例程序时，我用一个编译器从它的源代码产生一个 Java 类文件。当我用Microsoft Internet 浏览器测试编译好的Applet 时，我使用Microsoft´s Just-In-Time 编译器来加速Java Applet 的执行（参见 MSDN 库中的“Just-In-Time 编译器的描述”，基本知识文章 Q154580）。
 
    什么是被编译，什么是被解释？Java 编译器产生的二进制指令（被称为字节代码）是由一组崭新的虚拟机本身的低级机器指令组成。用于解释已编译Java 字节代码的虚拟机作为被创建的一个软件机器本质上讲可以运行在任何计算机上——甚至可以被创建为一个新的硬件平台，它使用Java 字节代码作为它自身的机器指令。换句话说，Java 虚拟机可以用硬件或用软件实现，而Java 程序并不“知道”其中的区别。事实上，如果Sun Microsystems JavaStation（一种被称为网络计算机的想法）直接执行Java 字节代码（我不能肯定的说），我们可以认为Java 程序是在由软件实现的 Java 虚拟机上仿真。在一个完全不同的计算机上仿真为另一个计算机结构编写的程序这一概念当然并不新鲜。例如，一些十分热爱他们旧的8位游戏的人们费尽心机的使自己可以在 PC 上继续玩。但Java 精确定义的语言规格和虚拟机目的在于使其可以运行在不同的结构上。这成了Java 被那些关心跨平台移植性的人们感兴趣的核心因素——它提供了一个精确定义的语言和虚拟机规格，使在任何计算机平台上创建虚拟Java 计算机成为可能。