Eric E. Allen (eallen@cyc.com)
Java 软件开发人员带头人，Cycorp, Inc.
2001 年 5 月

在象 Java 语言这样的面向对象的语言中，方法是可重载和可覆盖的，即便在中等复杂程度的程序中，方法调度也会给代码管理带来困难。在本周的诊断 Java 代码中，Eric Allen 讨论了由这些困难导致的错误模式，概述了由于参数不匹配导致的错误方法调用的征兆，同时给出了应对这个问题的一些办法。

整体和部分
还记得这条谚语吗，“整体大于部分之和”？如果把一个个独立的事件组合成一个相互作用的整体，产生的结果会比单个个体的作用之和要大得多。

程序也是一样的道理。随着一个个新方法被添加到程序中，整个程序可能的控制流程迅速增加。对于大型程序而言，很快局面就会无法控制了。就象是一个荒谬而又不可思议的戏法，有时您得到的最终结果并不是您所期望的方向 — 这同您在重载方法或者覆盖方法时遇到的情况有些类似。

Broken Dispatch 错误模式
面向对象语言的最强大的特性之一就是继承多态性。这一特性允许我们根据参数类型重载和覆盖方法。但是，象其它功能强大的工具一样，这个特性也会引入新的危险。

虽然 Java 程序员们很快就能学会管理一次调用中将调用哪个方法的规则，但在大型程序中却很容易出现这种情况：在一个类中重载了一个方法，结果却是以前在另一个类中可以运行的代码被中断了。这样的错误正符合我所说的 Broken Dispatch 模式。

该模式可以描述如下：

• 传递给某个重载方法，比如 foo 的参数，却被传给了另一个方法，比如 goo，它支持更广泛的参数类型。
• goo 然后通过这些参数调用 foo。
• 但是由于 goo 内的这些参数的静态类型更为广泛，因此，可能会调用方法 foo 的错误版本。

象这样的错误很难诊断，因为可能只是添加了新的方法（而不是修改现有的方法）就引入了错误。而且，在发现问题之前，程序可能会继续执行相当长的一段时间。

症状
为了说明这种模式的本质，让我们来看看下面这段示例代码，它是为实现我前面的文章“空标志错误模式”中的不可变列表而编写的。

清单 1. 实现不可变列表

interface List {
  public Object getFirst();
  public List getRest();
}

class Empty implements List {
  public Object getFirst() { throw new NoSuchElementException(); }
  public List getRest() { throw new NoSuchElementException(); }
  public boolean equals(Object that) { 
    return this.getClass() == that.getClass(); 
  }
}

class Cons implements List {
  
  Object first;
  List rest;
  
  Cons(Object _first) {
    this.first = _first;
    this.rest = new Empty();
  }
  Cons(Object _first, List _rest) {
    this.first = _first;
    this.rest = _rest;
  }
  public Object getFirst() { return this.first; }
  public List getRest() { return this.rest; }
  ...
}

在那篇文章中，我们把链表实现作为这些不可变列表的容器。

假设我们在一个独立的包中实现链表，我们知道这个包中类 LinkedList 的所有实例都将是 String 列表。我们可以象下面这样编写构造函数来强制定义该不变量：

清单 2. 为链表定义强制参数

public class LinkedList {

  private List value;

  /**
   * Constructs an empty LinkedList.
   */
  public LinkedList() { this.value = new Empty(); }

  /**
   * Constructs a LinkedList containing only the given element.
   */
  public LinkedList(String _first) { this.value = new Cons(_first); }

  /**
   * Constructs a LinkedList consisting of the given Object followed by
   * all the elements in the given LinkedList.
   */
  public LinkedList(String _first, LinkedList _rest) {
   this.value = new Cons(_first, _rest.value);
  }

  public Object getFirst() { return this.value.getFirst();  }

  public LinkedList getRest() { 
    return new LinkedList(this.value.getRest()); 
  }

  public void push(String s) { this.value = new Cons(s, this.value); }

  public String pop() {
    String result = (String)this.value.getFirst();
    this.value = this.value.getRest();
    return result;
  }

  public boolean isEmpty() { return this.value instanceof Empty; }

  public String toString() {...}
  ...
}

假设我们写了这些代码，并且所有的测试案例都可以正常运行。（或者，更现实些，假设它起初并不能正常运行，可经过几个调试周期后，我们使它变得能够正常运行了。）

也许几个月后，您开发了类 Cons 的一个新构造函数，它使用列表的 String 表达作为其唯一的参数。这种构造函数非常有用 — 它允许我们用下面这样的表达式构造新的列表：

清单 3. 新构造函数仅使用列表的 String 表示法作为参数

  new Cons("(this is a list)")
  new Cons("(so is this)")

这样，我们写了这个构造函数而且它的所有测试案例也正常运行了。太棒了！但是，接着，我们发现，太不可思议了，类 LinkedList 的方法测试中有一些突然中断了。发生了什么事？

起因
问题在于类 LinkedList 的构造函数，它只有一个 String 作为参数。

这个构造函数以前曾调用底层的类 Cons 的构造函数。但是，既然我们用一个更加明确的方法 — 该方法只有一个 String 作为参数 — 重载了这个构造函数，那么被调用的就是这个更加特殊的方法了。

除非传递给 LinkedList 构造函数的 String 是一个有效的 Cons 表示法，否则试图对其进行语法分析时就会导致程序崩溃。更糟糕的是，如果 String 正好是一个有效的 Cons 表示法，程序就会使用这些毁坏的数据继续执行。如果那样的话，我们就在数据中引入了一个破坏者数据。关于破坏者数据的讨论，请参阅最后一部分，“破坏者数据错误模式”。

Broken Dispatch 错误，与所有的错误模式一样，在“布满测试”的代码（借用自极端编程术语）中最容易诊断，在这种环境中连最微不足道的方法也有相应的单元测试。在这样的环境里，最为一般的症状是为您从未碰过的代码编写的测试案例突然中断运行。

如果这种情况发生，有可能是 Broken Dispatch 模式的一种情况。如果测试案例中断是在您重载另一个方法后立即发生的，那就几乎可以肯定。

如果这段代码没有经过布满测试，情况就变得更加困难了。错误症状可能表现为，比如，返回速度比预期快得多（并且结果错误）的方法调用。换句话说，您可能会发现本来应该发生的某些事件从未发生（因为正确的方法未曾被执行）。

要记住，尽管类似的症状也可能是其它错误模式的缘故。但是，如果遇到这种的症状，最好是开始写更多的单元测试，从发现错误的方法开始，回退测试程序执行的过程。

治疗和预防措施
关于这个错误模式的好消息是有一些简单的解决方案。最直接的一种方法是把方法调用中的参数上溯造型。在我们的示例中，这意味着重写相关的 LinkedList 构造函数，如下所示：

清单 4. 在方法调用中上溯造型参数

  public LinkedList(String _first) { 
    this.value = new Cons((Object)_first); 
  }

当然，这种办法只解决了调用 Cons 构造函数这个问题。还有其它地方的调用，我们也得上溯造型，这种技术对于 Cons 类的客户来说是很讨厌的。在这样的情形下，您就得权衡一下，应用这个方便的构造函数给您带来的好处以及它引入错误的潜在危险，二者孰重孰轻了。

接口的表达性和健壮性之间的平衡也存在这种困境。一种两全其美的方法是用一个 static 方法来替代这个 Cons 的 String 构造函数，该 static 方法只有一个 String 作为参数并返回一个新的 Cons 对象。

总结
以下是对上面这个错误模式的总结:

• 模式: Broken Dispatch
• 症状：在重载了另一个方法之后，测试您从未碰过的代码的测试案例突然发生中断。
• 起因: 重载使得未碰过的方法调用了一个方法，而该方法不是您希望调用的那个方法。
• 治疗和预防措施：插入显式上溯造型。或者，重新考虑您提供给不同的类的方法集。

记住，当您重载或者覆盖一个方法时，参数结构是确保按意图调用方法的一个关键部分。

下个月，我们将暂停错误模式的讨论转而处理其它一些重要的课题。诊断 Java 代码的下一部分将考查尾递归方法如何影响 Java 程序的性能。请不要担心，我们很快就会回到错误模式上来。

参考资料

• 参加本文的讨论论坛。
• 务必把 Java 语言规范加为书签，该书提供不错的关于方法调用规则的讨论。
• 经典的 Java VM 里有一个错误，导致方法覆盖不能正确的调度除它们的父类以外的包里定义的某些子类。请参阅 Sun Web 站点的讨论以获取详细信息。
• Bill Venners 的 Under the Hood（JavaWorld，1997 年 6 月）讲述了 JVM 中方法调用的字节码实现。
• 下载 JUnit 并使您的代码“布满测试”。
• 要得到更多的关于极端编程方法的信息，请阅读“XP 精华”（developerWorks，2001 年 3 月），它提供了关于这种非常受欢迎而且灵活的进程的优秀文摘。
• 阅读 Eric 的诊断 Java 代码的完整系列。

Cameron Laird (Cameron@Lairds.com)
副总裁， Phaseit, Inc.
2001 年 8 月

Web 服务正在开始应用于生产。这一关于短消息服务应用程序的个案研究分析了与电信服务 中的 Web 服务开发相关的问题。

Web 服务已“投入生产”。尽管许多商业新闻坚持将 Web 服务作为一种未来的技术进行报道， 然而它已经开始为各种组织机构解决问题了。该个案研究简要描述了一个成功的公开的运用推广在为其编 码的程序员眼中是什么样的。

Web 服务方案便于管理吗？这是一个困扰着许多运用推广计划的关键的不确定因素。developerWorks Web 服务专区的读者们早已认识到 Web 服务是一项可靠的技术，它会在不久的将来变得极为重要。然而 方案计划和实行的结果又是什么呢？Web 服务工作与前几代的客户机-服务器式或基于主机的编程有何不 同呢？Lucin 的公共短消息服务（Short Message Service，SMS）为这些问题提供了线索。

服务运用的种类
首先，让我们来考虑一下 Web 服务的产业环境。如今大多数这样的方案都能归入以下四个类别之一：

1. 内容管理、协作与联合。这方面的公认的领军者是 Dave Winer 的 Userland、O'Reilly and Associates 的 Meerkat 业务，以及 Jon Udell 为 Linux Magazine 以及 Byte.com 所作的开发和所写的文 章。
2. 内部服务合并。与 1995 和 1996 年所爆发的“intranet”有所不同，不少 Web 服务的开发是避开公众 视线，在防火墙后展开的。战略上依靠技术多样性的组织机构正将其内部接口作为服务来合并。
3. CORBA 和 DCOM 的替代品。用 CORBA（更确切地说是 IIOP）或 DCOM 来执行方案或许还是可行的，人们 在去年还采用这种方法。 然而今年，决策者们开始选用 Web 服务作为这些具有竞争力的分布式计算协议的技术替代品了。
4. 那些以 CORBA 和 DCOM 无法比拟的方式充分利用 Web 服务的公共特性及互操作性的“以程序员为中心” 的方案。

该个案研究可归入这些类别中的最后一个：Web 服务为该应用程序带来了 CORBA 和 DCOM 无法与之匹 敌的重要优势。DCOM 本质上将用户限制为那些运行在 Windows 桌面的用户。而另一方面，CORBA 对于网 关所要求的简单处理来说显得过于“笨重”了。不仅如此，现实中的 CORBA 方案素有受防火墙和互操作 性问题的牵绊之名，而这些问题 Web 服务都能轻松地加以解决。

开发小组：重要统计资料
Lucin PLC 是一 个总部设在英国威尔士的 Newport 的小型软件咨询公司。Mike Clark 是它的创始人和常务董事。它投身 于面向事务的客户机-服务器应用的专业研究已有十余年。2001 年 2 月，三个工程师开始着手于一个“ Web 服务到 SMS”网关的小型演示。几周后，在 3 月份，它就将此项服务向公众开放了。

在大多数欧洲和亚太国家或地区，那里的无线电话都普遍支持“短消息服务（Short Messaging Service）”或者“短消息发送（Short Message Sending）”，尽管这在美国很少见。在日本和其它地区 热火朝天的 SMS 允许电话用户使用手机撰写短小的文本消息，并将它们进行异步传输。它们可被 视为蜂窝式电话的即时消息传递。

相关的电话技术和计算协议捆绑在一起是很自然的，这样计算机就能产生并有可能接收这样的消息了 。 这便是 Lucin 在其“Web 服务到 SMS”网关中所取得的成就；它是未来几个月中几个收费网关中的第一 个：

• Web 服务到寻呼机
• Web 服务到传真
• Web 服务到语音
• Web 服务到电话应用程序编程接口（telephony application programming interface，TAPI）

在 Lucin 的计划中，再过一段很短的时间，或许就是 2001 年的最后一个季度，它就会具有拨打一个传 统电话，然后用合成的语音读出一条任意消息的能力了。

然而其出发点是 Web 服务与 SMS 的集成。 让我们更仔细地看看第一步。

一种 Web 服务的结构
SMS 网关是一个小 型的软件方案。 许多关于 Web 服务的媒体宣传都设想在大型供应链方案上集成企业应用。Clark 坚持认为，这忽略了一 个要点，那就是“即时满意服务”针对普通的、明确规定的方案，已经运用到了生产中。他有意选择了 SMS 作为模型。 正如 Clark 所指出的那样，“［SMS］就象有着极好使用效果的 Web 服务一样完美地符合这一［模型］ ，”但也可能遇到偶尔的供应中断或停机。

当前的基础设备导致我们不得不容忍这些问题。毕竟网络还不是百分之一百的可靠或无所不在的。

一些 Web 服务厂商将“革新”连同其 Web 服务工具的智能性一同兜售。然而不论这个软件在实验室中运 行得如何出色，看上去很少有组织能拥有足够多的连接良好的客户来把那么多重量压在现有的网络上。不 论一个程序的纠错和事务算法有多聪明：除非基础网络连接能获得一笔价格和可靠性均相当可观的订单， 否则建立复杂的 Web 服务就没什么意义。Clark 总结道：“别指望您的用户会因响应时间的缩短而感到 高兴。目前这并非是我们所能掌握的；可能两年后情况会有所不同。”

当前网络基础设备的匮乏迫使 Clark 对 Lucin 作了适当的调整：“我们为一个三年的周期作了仔细 的预算，这意味着我们能在用户基数不大的情况下顺利地维持三年。因为我相信，还需要长时间的艰苦跋 涉，才能让人们认为长期使用 Web 服务对企业来说是足够可靠且值得信赖的。”

与此同时，那几种确实能满足用户的服务可能比您期望的更为简单。Web 服务开发人员将典型的高级 设计看作是从网络上引入数据或对象，对它们进行计算然后使用 Web 服务协议将结果传回网络。Lucin 出售大量符合这一模型的 Web 服务产品并有一些内部工具来支持这样的开发。

然而对于 SMS 网关，Lucin 最终决定采用一种甚至更为简单的方法。Clark 的解释是“……如果您知 道接口的话，便只需构建一个简单的字符串变量，并替换那些您向远程 Web 服务发送数据时会改变的值 。这就节省了不得不引用［SOAP 工具包或模块］所需的时间和开销。"

Lucin 用 Visual Basic 在位于一个 NT Server 4.0 上的产品级版本的 SMS 网关上进行这一简单的 字符串替换，以及其他相关的轻量计算。它所提供的性能对于每天处理的几百条消息（通常在 300 到 800 之间）来说已是绰绰有余了。

该网关的简单性扩展至到了其 身份验证部分：一个通过超文本传输协议（HyperText Transport Protocol，HTTP）以纯文本形式发送的 用户—密码组合。Clark 指出：“您并不希望在登录 Web 站点时使用 HTTPS［安全 HTTP］，那又何必用 HTTPS 让用户传递用户名及密码以验证他们使用您的 Web 服务呢？”由于使用 HTTPS 的频率相当高， Clark 指出了其在运行时性能上的缺点，并作了总结：“我们可以在一定程度上使用 HTTPS 的能力，但 差不多应该只在收到用户请求时使用。”

“Web 服务的优点之一，”根据 Clark 的观点，“就是使用简单、牢固的部件所带来的灵活性。”网 关在后端与电信厂商所提供的计量的 SMS 接口相连接。Lucin 已经两度为这个后端改变了供应商，但却 没有中断任何针对客户的服务。网关的用户只需接收关于收到他们的请求的确认；而无需知道或关心后端 的情况。

身份验证，连同验证电话国家或地区代码和本地号码的接口一起，使该网关的 Web 服务描述语言（ Web Services Description Language，WSDL）实例成为一个最广泛使用的公开可见的服务（请参阅参考 资料）。它定义了四种操作：SendTextMessage、SendMessage、 ValidPhoneNumber 和 GetCountryCodes。其中第二种操作的部分定义如清单 1 所示。

清单 1：process.xml

       <message name="SendMessageRequest">
         <part name="PhoneNumber" type="xsd:string"/>
         <part name="Message" type="xsd:string"/>
	 <part name="SenderName" type="xsd:string"/>
	 <part name="SenderPassKey" type="xsd:string"/>
       </message>
  

Lucin 在该方案中大量地重复运用了其在 Visual Basic 及其同类技术方面的专长。Clark 透露：“ Web 服务只是 DCOM 组件的一个层。”

根据 Clark 的观点，该网关接下来的变化将是：“将它发展成为一种收费服务，”价格为每次 4.5 便士，并与电信供应商签约，合作开发上面提到过的寻呼机、传真以及其它网关。

可操作性结论
作为一个软件方案，SMS 网关是很小的：其设计、实现和部署只需要十几个工作周。由于竞争方面的原因 ，Clark 不愿提供编码的细节。而他公开提出的部分观点是，Web 服务提供了基于组件的软件开发的优势 。适合于 Web 服务的几套要求常常自然分解为即使是初级编程人员也能进行的简单设计。

其它的公共 Web 服务在工程范围内同样看起来很小。XMethods.net 有一个通往 PacBell SMS（在美 国西部）的网关。它有个更为简单的公共接口（请参阅参考资料），仅处理 一个 WSDL operation：sendMessage。最为复杂的公共服务接口是 Lucin 的邮件列表管理器演示。它定义了二十六个不同的 operation，所处理的所有数据类型都 很简单，如 string。

那么，Web 服务开发有什么特别之处呢？我们都还无法确定。尚未有过任何一家从事大规模的基于 Web 服务开发的公司过多透露他们的经验。在小范围内，这一技术“感觉”就像是其它轻量级的网络的开 发。人们能够阅读 XML，并且有这么多工具可供人们管理使用，这无论如何都是个优点。

Clark 认为：“开发 Web 服务的问题并非开发周期，而是力图创建一个人们愿意为之付钱的 Web 服 务。”随着 Web 自身开始了其第二个十年，基础技术已被理解得相当透彻，但是在为人们可读的 Web 站 点建立“商业模型”方面，仍有许多不能令人满意之处，还需要做大量实验。这也将成为外部 Web 服务 — 介绍中所提到的第四个类别 — 的最大挑战。

当 Web 服务的“组件市场”在 OCX 或 VBX 实践的方式的逐渐成熟起来的时候，它的开发工作也将发 生重大变化。 这一技术已经强调了对构件的使用，而它很可能还会随着越来越多的服务联机入网而不断加强。其中的一 个不同可能就是开放源代码的影响。虽然 OCX 和 VBX 拥有所有权定义，并且授权收费的组件总是统制着 那个领域，然而由于 Web 服务是完全基于公共标准的，因此该技术的许多工具包都是开放源代码的。

参考资料

• Userland 主页：Dave Winer 的 Userland 是关于 Web 服务内容企业联合组织及相关事物的热衷者和各种实验的可靠场所。
• “Meerkat, an Open Wire Service”，O'Reilly 的演示给了 Web 服务一个新面貌。
• 请查阅 Linux Magazine。
• 请访问 Byte.com。
• GSM-SMS 概述
：SMS 的技术概述 。
• 请在“Short Message Sending for Wireless”学习 developerWorks 教程。
• 请查看 Lucin 的 SMS 消息传递 SOAP Web 服务。
• 这里是 Lucin SMS 网关的 WSDL 实例。
• 请阅读 Microsoft 白皮书，“IP Telephony with TAPI 3.0”。
• Bowstreet 关于紧密结合、普遍存在的 Web 服务的雄心勃勃的设想可在白皮书：“Bowstreet - Beyond B2B”中可见一斑。
• XMethods.net PacBell SMS 的 WSDL 实例。
• Lucin 邮件列表管理器的 WSDL 实例。
• 请阅读 Cameron Laird 个人关于 Web 服务的 记录。

本文概述了在旧金山举行的2001年全世界Java开发者大会的盛况，各种Java产品的展示和对未来Java技术发展趋势的展望，以及作者参加会议的体会。

1. 概况:
初夏的旧金山,凉风飕搜,夜间寒气逼人，加上近几个月美国经济下滑，各个公司不断辞退员工的消息更增添了人们心理压抑与紧张的气氛,但 JavaOne 2001全世界开发者大会的召开, 却给旧金山带来一股热气和欢快的气氛, 天上整天由一架双翼飞机拖着巨型Java会议的广告条幅在盘旋，地上则是近百辆摩托车队，插着Java会议的广告条旗"呼啸而过、招摇过市"，引得行人纷纷行"注目礼"， 来自全世界各地的 21000多名Java开发者和爱好者参加了这次大会,有345个公司在展览会上展示各自的Java产品, 大会上共有1200余人发言（包括大会主题报告、技术专题报告、BOF专题讨论会），收到了1000余篇文章;大会的统计资料表明, 全球超过 85%的大型企业正在用Java 开发自己的信息系统, 业界公认: Java 已进入主流计算模式,在美国高等学校中已有80%以上的开设了Java 课程, 已经出版的 Java 书籍超过了2500种;SUN公司的软件产品开发部的总经理Sueltz说: "Java+XML是网络经济的驱动力"; 占全世界95%市场份额的智能卡制造公司都已被授权使用 Java 平台, 预计2001年市场的份额将达到34 亿美元,因此, 信息技术市场的发展正由 Java 来推动;由于对Java 人才市场需求的奇缺, 使得Java 的培训与考证热遍硅谷, 各大公司都在纷纷采取措施, 以争夺Java人才, 以争取在IT市场的主动权.!

华尔街的金融巨头曾经在今年的2月，专门在世界贸易中心召开了一个"2001 Wall Street on Java Technology"会议，会上众多金融巨头几乎一致性地作出了"把Java平台作为金融业开发者的战略选择"，认为下一代企业信息化必将以J2EE 为基础框架，这个消息由会议特刊"JavaOne Today"披露出来，对IT 业界产生了不小的震动，因为华尔街老板的举动往往对经济、技术的发展带有导向性作用，成为全球经济发展的风向标，而技术界则往往把它动向看成这个风向标上的定向器，因此，Java 必将象有人在会上报告中比喻"Java的出现和使用象塑料的发明一样，渗透和影响着人类的生活"。

2. 会议特色
大会共有7个专题, 但最吸引人的、突出的话题是Intelligent Web Service (智能Web 服务)、移动计算（J2ME嵌入到手机中）、下一代的企业综合信息求解方案（J2EE）和JXTA（分布计算技术）。

1. Web Service (Web服务)，主要在于通过Web 进行交互式信息定制服务、B2B（B2C）的电子商务的交易活动；
2. Mobile Computing（移动计算）是会场上普遍都在议论的话题，无论是大会报告还是 Pavilion(产品展示)，都是吸引人的地方；
3. J2EE居于会场四大平台之首，SUN公司已发出29 个J2EE 的使用许可证，其中包括IBM、Oracle、 Motorola、 BEA等，这些公司都在不遗余力地推广J2EE 的使用；
4. 这次会议上涌现出众多的以Java 起家的新兴软件公司，其中尤为突出的是BEA公司，他们以WebLogic 为拳头产品，号称"世界头号电子商务平台"，成为会场上一棵耀亮的明星，以至于可以与全球第二软件巨头Oracle 平起平坐，他的总裁 Bill T.Coleman III 和 Oracle 的总裁Lawreance J.Ellison竟在万人大会上打起了"擂台"，做起了竞争演说，把会场气氛推向了又一个高潮，BEA公司在全世界的客户已有9400多个，几乎囊括了世界500强的企业，该公司的e-B 构件库已成为品牌产品，独占电子商务市场，现有员工接近2000人，而该公司仅仅是95年Java正式发布后由三个发起者成立的小公司；

3. Java的发展趋势

1. IWS(Intelligent Web Service) 智能Web服务是未来IT产业的发展方向，是信息化社会的必由之路，会议中有人认为IWS将是下一代Internet革命的发展方向，包括个性化的信息定制服务（如股票信息查询、货币网上兑换处理等）、电子商务（货物定单、物流配送）等；
2. 移动计算（移动电子商务，移动通讯设备的巨挚诺基亚（Nokia）的总裁Pekka J.Pietila在会上大出风头，频频亮出各色Java手机，他预言：2003年全世界将会推出 1亿只Java手机，使得"移动计算无处不在，到处都能进行电子商务活动"；JavaCard 在无线市场上的潜力会越来越为人们所接收, 人们只要持有一张Java 卡, 在社会就能通行无阻.
3. 以JXTA为架构的分布计算可能是Internet 发展的又一个新时代，这个架构的基本思路就是不再依靠原来的"以某一个Web为中心，进行点-点的通信控制机制"，而是"在某一协议下直接进行Peer-To-Peer"的通讯模式，使得各色电子、电气设备都可以直接联接到Internet上，这可能对分布对象计算、资源的共享与优化配置、多模式交互通信等研究和应用领域都可能产生深远的影响；
4. 企业的信息化处理, 尤其是基于Web技术的电子商务, B2B的模式是今后企业生存与发展的必 不可少的基础, Intel公司的总裁巴瑞特曾经说过:"不上网的企业必死无疑 !"（最近他在一次 IT业界大会上又重申了这一观点），会上以BEA为首的一些软件公司纷纷以J2EE为基础平台，构造能适合各种企业所需要的电子商务Solution，而其实现的基本途径就是"构造构件库"的思路，尤其是BEA 靠大量销售、出租Components的办法，在全世界电子商务市场上具有举足轻重的地位，受到与会者的高度重视；
5. Java+XML的结合, 尤其是将 EJB+XML用于电子商务(B2B)的模式,认为这是B2B的驱动力, 因为不管什么类型的电子商务, 企业之间的业务往来都是不同数据结构之间的信息交换, 即异构信息结构的转换和处理, 而这正是XML所能解决的问题, 各行各业都在纷纷上马电子商务, 尤其是 B2B(企业的综合信息系统) 的模式, 受到相当多的大型企业的重视, 如通用电气公司(GE),正在积极地构件B2B的框架, 用 Java 技术就是他们的首选平台;
6. 嵌入式Java技术,通过嵌入各种类型的传感器和Java技术,即无处不在的计算模式,如 Java卡,所谓"社会一卡通",人们走在社会的任何角落,凭着这张卡就进行商务活动, 定飞机票,查询资料, 发电子邮件,看天气预报等等; 展览会上,把Java技术嵌入到交互电视中, 也是吸引人的一个项目,人们只要用遥控器就能在家里点播所需要的任何电视节目,并且可以与电视节目中的角色进行交互对话;
7. 实时Java, 如实时性比较强的天气预报, 国防与航空控制等领域, 如飞机驾驶仓中的仪表控制都已经出现用Java技术实现的系统,受到出席会议的用户的青睐.

4. 反思与体会

1. 企业对 Java的试用热度在不断地升温,从超大型的通用电气公司到中小行企业,都在纷纷转向B2B的模式, 我们应当抓住这个机遇;B2B的框架, 很重要的就是能提供基于Web技术的 Solution(综合问题求解方案), 由于用户使用的平台不同, 客户的环境相异, 因此通过 Java 来进行架构, 是比较理想的途径;因此,我国的企业要想发展, 适应WTO, 必须上马B2B, 这是迟早的事情, 企业的领导应有一个清醒的认识, 而Java+XML 几乎是唯一首选的技术与工具;
2. 目前美国社会与经济的发展出现了滑坡现象, 但始终抓住与支持高新技术的发展, 是不可否认的共识, 而注重人才的培训, 是所有大中小公司的都非常重视的一个企业生存与发展的战略性措施, 培训Java人才,就是作为人才竞争的一种手段;
3. Internet 的普及和深入社会生活, 对人们的日常生活的影响, 可以说怎么估计都不为过分, 因此,通过Internet 进行全球范围的交互通讯, 协作求解某一问题, 已成为现实与可能, 会议中不少人认为"下一个十年是实时协作计算的时代",即嵌入领域与RTOS的结合;
4. 在网络计算模式下, 今后任何人, 在任何时间, 在任何地方都能从Web 上获取任何知识,获取任何模式的服务与信息, 也就是KOD(SOD) 模式(Knowledge On Demand, Service On Demand);
5. Internet的迅猛发展和基于Web技术的信息服务已经渗透到人类社会的方方面面，在我们的经济发展和科学研究中，必须增强网络意识, 达到资源共享的目的，而Java 和XML则是重要的工具；
6. 在科学研究和技术开发中要建立创新意识，必须从科学技术源头上创新，社会的信息化覆盖面很广，其源头就是要把社会事务"分门别类、分类管理"，这就是"面向对象"的技术和方法，而软件的可重用思想则是这个方法的体现，起实现的途径就是"构件库设计"，近年来一些发展迅速的信息公司就是通过"构件库设计"来达到目的的，如著名的电子商务平台供应商BEA公司，在5年时间里由三个人猛增到3000余人，市场实力能与Oracle较真，就是一例。因此，通过J2EE和EJB来实现"构件库设计"，提供实现社会信息化创新的基础实施，为社会的发展和人类社会的进步作出贡献。

　　与现有的技术相比，Java有明显的优点，因此它已经在服务器端应用软件的开发中确立了主导地位。然而，由于每一个应用程序都有几种形式的用户界面和前端的表达形式，我们中的许多人都对在客户端采用Java技术有不好的印象，因此在客户端的开发中采用HTML似乎已经成为唯一的选择了。

　　实际情况是，在客户端应用程序的开发中不止只有HTML一种选择，我们将在本文讨论基于Java的应用软件开发中三种用户界面的解决方案。我将首先讨论HTML与JSP和servlet联合使用的优点和缺点，然后讨论Java最初的目标之一：通过GUI Applet实现交互式互联网。最后，我们将讨论XML以及由它所衍生出来的其他技术。

　　JSP/Servlets环境下的HTML客户端

　　大多数读者都曾编写过servlet、开发过JSP应用，清楚基于HTML的用户界面的优点和缺点。选择HTML的最大的理由仍然是其广泛的平台适应性，基本HTML的标准性很好，虽然比较枯燥，但它可以很好地完成工作。

　　由于HTTP/HTTPS协议非常简单，可以使开发的应用程序很好地适应各种网络配置和防火墻。但这是有代价的，HTML缺乏与用户的交互性，而且对用户每个行为的响应都需要与服务器进行连接。作为一名编程人员，我们一直在追求简单性，并使开发的软件可以适合所有的浏览器？然而简单性并不总是好的，简单地说，与静态HTML相比，JavaScript可以较好地实现不太复杂的交互性，但对于开发复杂的用户界面而言，它还是不能胜任的。

　　除非拥有高速的互联网连接，否则你一定有过焦急的等待加载一个网页的经历。尽管瘦客户端提供了一些很好的非交互性的用户界面，但传统的胖客户终端一般情况下都比它们更聪明。例如，Netscape Communicator和MS Outlook等电子邮件的前端就比基于互联网的电子邮件工具具有更好的用户亲和性。

　　用Java开发一个HTML前端应用是一个很好的选择，因为HTML提供了跨平台的内容传输能力。编程人员可以使用Java Servlets和JSP开发在任何操作系统平台上运行的服务器端应用程序。同时考虑到众多的Java API和它得到的广泛的服务器开发商的支持，对于开发可伸缩互联网站而言，Java是一种理想的选择。

　　总而言之，配合使用Servlets和JSP的HTML前端开发工具是开发静态界面的很好的方式，但当需要对用户的行为作出快速反应和需要对数据进行高速处理的复杂应用时，这种方式则不大理想。

Hello and Welcome

Hello There"+name + "!

我的面向对象程序观

1)面向对象概念的一些误解

“面向对象”是一个如今被人叫烂的词汇，就像去年人们都喜欢把自己的公司打上“.com”的标记一样。其实有多少人能真正理解这个词汇呢，很难说。我喜欢这样来比喻人们对“对象”一词的滥用。“对象”就好比人们经常说的“酷”和“爽”，很多人并不仔细考虑这两个词的差别，在很多情况下他们是通用的，“酷”和“爽”通常表达“心情不错”的意思，你可以在你玩的高兴的时候，大声的叫嚷“太酷了，太爽了”，这个时候两个词汇是通用的。但是你可以说“这个人很酷啊”，但是你不能说“这个人很爽啊”。人们对“对象”这个词汇的滥用就发生在这里，“面向对象”和“基于对象”就好比“酷”和“爽”,这是两个不同的概念，但是人们通常将这两个词汇混为一谈，一律用“面向对象”来表达。常见的错误可以在此列举一些：

1）有个人兴高采烈的和你说“我不喜欢 flash 4 的脚本语言，flash 5 版本的 action script 采用了新的面向对象的“.”语法，写起来很舒服。我现在一直用 flash 5 来做东西。”（同样的话语也发生在 director 的 lingo 脚本语言中）

2）visual basic 采用了面向对象的属性和方法，比起过去的 basic 语言有了很大的提高。

3）javascript 是面向对象的。

等等。

通常听到类似的话，你都要认真审视说话之人，分析他说的话。可以肯定一点，他并非真正懂得什么是面向对象的思想。很多人没有区分“面向对象”和“基于对象”两个不同的概念。面向对象的三大特点（封装，继承，多态）却一不可，通常“基于对象”使用对象，但是无法利用现有的对象模板产生新的对象类型，继而产生新的对象，也就是说“基于对象”没有继承的特点，而“多态”是表示为父类类型的子类对象实例，没有了继承的概念也就无从谈论“多态”。现在的很多流行技术都是基于对象的，它们使用一些封装好的对象，调用对象的方法，设置对象的属性。但是它们无法让程序员派生新对象类型。他们只能使用现有对象的方法和属性。所以当你判断一个新的技术是否是面向对象的时候，通常可以使用后两个特性来加以判断。“面向对象”和“基于对象”都实现了“封装”的概念，但是面向对象实现了“继承和多态”，而“基于对象”没有实现这些，的确很饶口。

2）java 比 c++  在贯彻面向对象的思想方面更加彻底。
我最近上的学习班的老师对我说：“c++ 是打着面向对象的幌子，干着过程编程的勾当”，这句话我非常的赞同，而且我一直以来也是这么认为的。但是仔细听他讲解后，我才发现，我是只是理解了这句话前两层的意思。但是还有一层意思我没有理解。你可能要问，“难道 c++ 不是面向对象的吗？”。事实上 c++ 是真正的面向对象编程语言。但是它也是过程编程语言。为什么怎么说呢， c++ 的产生不但考虑了面向对象的特性，而且也更多的考虑了对 c 语言的向后兼容，使得 c++ 这种杂合语言表现出“过程”和“对象”编程的双重性。你通常既可以继续用 c++ 编译器来编写传统的 c 程序，也可以使用 c ++ 的类库或者编写自己的类来作面向对象编程。这种“两面性”使得人们可以继续保留原有的 c 代码，同时也阻碍了面向对象思想的推广。

举个简单的例子，94 年的时候，我开始学习 c++ ，当时是学习 turbo c++ 自己带的一个叫作 turbo vision 的类库来做项目。我的同学也用 turbo c++ ，但是他一点也没有学习过 c++ 这个语言，他只是用 turbo c++ 编译器来重新编译他以前用 turbo c 写的程序，然后他自豪的对我说：“瞧，我用 c++ 做的东西”，好像意思是说“我用 c++ 开发项目了”，在那个 c 比 pascal 高档， pascal 比 foxbase 高档的年代里， c++ 的标签绝对是个很"酷"的标志。我其实很清楚他的行为。这就是“c++ 是打着面向对象的幌子，干着过程编程的勾当”的第一重意思，也就是说， c++ 编译器对 c 程序的兼容性造成了最底层的“过程勾当”。在国内有很长一段时间，人们都是在用 c++ 编译器做 c 编程。 我当时在想，比起我那个同学，我才是真正懂得面向对象的人。 我学习了 c++ 语言，我懂得封装，继承和多态，我学习了 turbo vision 的类库，我派生了 turbo vision 的类库并编写了自己的类，所以我是懂得面向对象的。从某种意义上说，我这么想是对的。但是从面向对象程序员的分类来说，我又不完全懂得面向对象的思想。从事面向对象编程的人按照分工来说，可以分为“类库的创建者”和“类库的使用者”，通常创建类库的人才是真正懂得面向对象思想的人，他们创建类库供给那些“客户程序员”来使用，他们从头开始制作类库，他们进行面向对象的分析，设计，实现的全过程。当学习完 c++ 后，我的第一个感觉是，从头创建一个类库真是很麻烦的事情，通常用 c 过程编程很容易实现的功能，你必须按照类的思想来从新建立对象，但是一旦类库建立好后，使用类库和派生类，以及维护代码都是非常舒服的事情。使用类库的人并不都是具备了面向对象思想的人，通常知道如何继承和派生新对象就可以使用类库了，然而我们的思维并没有真正的转过来，使用类库只是在形式上是面向对象，而实质上只是库函数的一种扩展。这就是我理解的“c++ 是打着面向对象的幌子，干着过程编程的勾当”的第二重意思，实际上用 c++ 编程的人，大部分不自己创建类，而是使用类库，这样就造成了他们把类库作为一种高级的库函数库来理解，并没有真正理解面向对象的思想。

c++ 的面向对象的思想推广很慢，直到 mfc ,owl ，vcl 这样的类库出来以后，人们才渐渐的接受了一些面向对象的思想。为什么这条面向对象的道路那么难走？我的答案是“因为 c++ 给了我们第二条道路去走过程编程”，当然原因是为了考虑兼容 c 语言，然而正是由于有了第二条老路才使得使得我们不会再去考虑新的面向对象编程思维方式。

直到出现了 java ，才真正迎来了面向对象的曙光。java 真正是革命性的东西吗？不是，所有现有的 java 的思想都是继承自其他的语言和技术，没有什么革命的地方，虚拟机的概念早在 20 年前的 ucsd pascal 中就采用了，只是当时的机器速度太慢，虚拟机仿真造成的性能降低对于当时的硬件来说是相当严重的。java 本身的很多东西也借鉴了 c++ 语言，连它的创始人也说，java 是 "c++--" 也就是说 java 去除了 c++ 的一些不太好的地方。所以说 java 本质上没有什么革命的东西，所以那些对 java 的赞美之词都是 sun 公司的宣传伎俩。没有一种语言会长久的存在下去，你很难说你的孩子在二十年后还会继续使用 c++ 或 java，所以我们要抛开这些浮华词汇的背后，找寻真正我们需要学习的东西。否则今天我们大家都是微软的傀儡，明天 sun 公司起来了，我们就都是 sun 的傀儡。仔细研究美国电脑技术发展的历史，美国人一向喜欢象第三世界兜售他们的过时技术，而他们始终可以自豪的说，我们将永远领先你们第三世界国家二十年。我们始终在跟在美国人的后面学习他们的东西，这的确让人担忧。我说着说着又跑题了。java 虽然没有什么真正的革命性的东西，但是 java 在真正推动面向对象编程思想方面是功不可末的。使用 java 编程，你无需考虑到向后兼容什么语言的问题，它是重新建立的语言，你在掌握这门语言之前，你必须将自己的编程思想由过程编程彻底转向面向对象编程，因为 每个 java 程序，本身就是一个类，你编写任何 java 程序，你都不自觉的在构造一个对象模板，没有第二条道路，只能是面向对象编程。（ 我非常喜欢 java 将所有类定义和类声明放在一个文件中，而不是象 c++ 那样，cpp 和 .h 文件是分开的。通常刚刚开始学习 java 的人不习惯，不过学习一段时间，你就会体会到它的好处了。）， 使用 java 编写程序（我更喜欢说---编写类，而不是程序）的时候，你会必须从一个对象的角度来考虑问题，因为你的程序就是一个类，你必须考虑把哪些东西作为成员变量，哪些作为方法，要生成几个类，哪些变量是成员变量，哪些是静态的变量和方法，等等。通常做完一个项目，你就已经将面向对象的思想运用其中了。之所以说 java 在面向对象的贯彻方面要比 c++ 彻底，就是因为你只能使用面向对象的方式来编写 java 程序，而 c++ 却可以采用另外一条非面向对象的方式来编写程序。java 并没有什么真正革命性的东西，它最大的贡献当然是推广面向对象的思想了。

java 总的来说是降低了继续过程编程的可能性，但是并没有完全消除它。面向对象是一种思想，是我们考虑事情的方法，通常表现为为我们是将问题的解决按照过程方式来解决呢，还是将问题抽象为一个对象来解决它。很多情况下，我们会不知不觉的按照过程方式来解决它，因为我们通常习惯于考虑解决问题的方法，而不是考虑将要解决问题抽象为对象去解决它。很多新的技术使我们更加趋向于过程而非对象的思想。最明显的就是 rad (快速应用程序开发）可视技术的出现，人们可以通过设置属性和编写事件函数来快速开发应用程序，编写事件函数就是典型的按照过程编程的思想（至少我是这么认为的），试问有多少人能区分vb 和 delphi ,c++ builder ，java 的事件函数编写有什么本质的区别， 后三者都采用了 delegation （委托模型），在 java 中是通过 anonymous 类（无名类），或者 adapter 类来实现delegation，这是一种面向对象的构想，但是 vb 不是，所以这底层的区别都被上层的相似性所抹杀了，使用 jbuilder 编程的时候，我们如果没有仔细研究 java 的 awt.event 编程方式的话，通常也是把它当作普普通通的“类 vb"的编写方式来写程序，而实际分析它在后台所生成的代码，你才能明白这些代码是真正的面向对象的，但是如果你只是简单的把它当作可视编程工具，你是永远不会明白什么是”委托模型“，什么是面向对象编程的。这是我理解的 “c++ 是打着面向对象的幌子，干着过程编程的勾当”第三重意思。无论是 c++ 还是 java 都有可能走过程编程的老路， java 降低的过程编写的可能性，但是如果你没有具备面向对象的编程思想，你还是可能走面向过程的老路的。 <淘宝热门商品：

摘要
将一类 java 资源打包在一个 java archive (jar) 文件中是缩短下载时间、增强安全性和增强可管理性的极好方法。这篇技巧说明如何很容易地从 jar 文件中提取资源以供您自己使用。

加载 gif 图像
假定我们有一个 jar 文件，其中包含我们的应用程序要使用的一组 .gif 图像。下面就是使用 jarresources 访问 jar 文件中的图像文件的方法：

    jarresources jar = new jarresources ("images.jar");
    image logo =
 toolkit.getdefaulttoolkit().createimage (jar.getresource ("logo.gif");


这段代码说明我们可以创建一个 jarresources 对象，并将其初始化为包含我们要使用的资源的 jar 文件 -- images.jar。随后我们使用 jarresources 的 getresource() 方法将来自 logo.gif 文件的原始数据提供给 awt toolkit 的 createimage() 方法。

命名说明
jarresource 是一个非常简单的示例，它说明了如何使用 java 1.1 所提供的各种功能来处理 jar 和 zip 档案文件。

关于命名的简要说明。java 中的归档支持实际上是以流行的 zip 归档格式为起点的（请参阅 "java tip 21: use archive files to speed up applet loading"）。因此，在最初实现处理档案文件的 java 支持时，所有类文件以及诸如此类的东西并未放在 java.util.zip 包中；这些类通常以 "zip" 开头。但在转向 java 1.1 时，功能已发生了变化，档案文件的名称也更具有 java 特征。因此，现在我们称之为 jar 文件的文件基本上是 zip 文件。

工作方式
jarresources 类的重要数据域用来跟踪和存储指定 jar 文件的内容：

public final class jarresources {

   public boolean debugon=false;

   private hashtable htsizes=new hashtable();
   private hashtable htjarcontents=new hashtable();

   private string jarfilename;


这样，该类的实例化设置 jar 文件的名称，然后转到 init() 方法完成全部实际工作。

   public jarresources(string jarfilename) {
      this.jarfilename=jarfilename;
      init();
   }


现在，init() 方法只将指定 jar 文件的整个内容加载到一个 hashtable（通过资源名访问）中。

这是一个相当有用的方法，下面我们对它作进一步的分析。zipfile 类为我们提供了对 jar/zip 档案头信息的基本访问方法。这类似于文件系统中的目录信息。下面我们列出 zipfile 中的所有条目，并用档案中每个资源的大小添充 htsizes hashtable：

   private void init() {
      try {
          zipfile zf=new zipfile(jarfilename);
          enumeration e=zf.entries();
          while (e.hasmoreelements()) {
              zipentry ze=(zipentry)e.nextelement();
              if (debugon) {
                 system.out.println(dumpzipentry(ze));
              }
              htsizes.put(ze.getname(),new integer((int)ze.getsize()));
          }
          zf.close();


接下来，我们使用 zipinputstream 类访问档案。zipinputstream 类完成了全部魔术，允许我们单独读取档案中的每个资源。我们从档案中读取组成每个资源的精确字节数，并将其存储在 htjarcontents hashtable 中，您可以通过资源名访问这些数据：

          fileinputstream fis=new fileinputstream(jarfilename);
          bufferedinputstream bis=new bufferedinputstream(fis);
          zipinputstream zis=new zipinputstream(bis);
          zipentry ze=null;
          while ((ze=zis.getnextentry())!=null) {
             if (ze.isdirectory()) {
                continue;
             }
             if (debugon) {
                system.out.println(
                   "ze.getname()="+ze.getname()+","+"getsize()="+ze.getsize()
                   );
             }
             int size=(int)ze.getsize();
             // -1 表示大小未知。
             if (size==-1) {
                size=((integer)htsizes.get(ze.getname())).intvalue();
             }
             byte[] b=new byte[(int)size];
             int rb=0;
             int chunk=0;
             while (((int)size - rb) > 0) {
                 chunk=zis.read(b,rb,(int)size - rb);
                 if (chunk==-1) {
                    break;
                 }
                 rb+=chunk;
             }
             // 添加到内部资源 hashtable 中
             htjarcontents.put(ze.getname(),b);
             if (debugon) {
                system.out.println(
                   ze.getname()+" rb="+rb+
                   ",size="+size+
                   ",csize="+ze.getcompressedsize()
                   );
             }
          }
       } catch (nullpointerexception e) {
          system.out.println("done.");
       } catch (filenotfoundexception e) {
          e.printstacktrace();
       } catch (ioexception e) {
          e.printstacktrace();
       }
   }


请注意，用来标识每个资源的名称是档案中资源的限定路径名，例如，不是包中的类名 -- 即 java.util.zip 包中的 zipentry 类将被命名为 "java/util/zip/zipentry"，而不是 "java.util.zip.zipentry"。

代码的最后一个重要部分是简单的测试驱动程序。该测试驱动程序是一个简单的应用程序，它接收 jar/zip 档案名和资源名。它试图发现档案中的资源文件，然后将成功或失败的消息报告出来：

   public static void main(string[] args) throws ioexception {
       if (args.length!=2) {
          system.err.println(
             "usage: java jarresources "
             );
          system.exit(1);
       }
       jarresources jr=new jarresources(args[0]);
       byte[] buff=jr.getresource(args[1]);
       if (buff==null) {
          system.out.println("could not find "+args[1]+".");
       } else {
          system.out.println("found "+args[1]+ " (length="+buff.length+").");
       }
   }

} // jarresources 类结束。


您已了解了这个类。一个易于使用的类，它隐藏了使用打包在 jar 文件中的资源的全部棘手问题。

练习
现在您对从档案文件中提取资源已有了一定的认识，下面是可用来修改和扩展 jarresources 类的一些说明：

• 不在构造期间一次性加载全部内容，而要延迟加载。对于大型 jar 文件，构造期间可能没有足够的内存加载全部文件。

• 不只是提供类似 getresource() 这样的一般读方法，我们还可提供资源特定的读方法 -- 例如，用来返回 java image 对象的 getimage() 方法，用来返回 java class 对象的 getclass() 方法（在自定义的类加载程序的协助下），等等。如果 jar 文件足够小，则我们可以根据它们的扩展名（.gif、.class 等等）预先构建全部资源。

• 某些方法应该提供关于给定 jar 文件本身（基本上是 zipfile 的包装）的信息，包括：jar/zip 的条目数；返回全部资源名的 enumerator；返回特定条目长度（和其他属性）的读方法；允许编制索引的读方法，这仅仅是举几个例子。

• 可对 jarresources 进行扩展，以供 applet 使用。通过利用 applet 参数和 urlconnection 类，就可以从网络上下载 jar 内容，而不是将档案作为本地文件打开。此外，我们还可将该类扩展为一个自定义的 java 内容处理程序。

小结
如果您曾经渴望知道如何从 jar 文件中提取图像，那么您现在已学到了一种方法。有了本技巧提供的这个新类，您就不仅可以用 jar 文件处理图像，而且可以将提取魔术用于 jar 文件中的任何资源。

参考资源

• 这是类文件 jarresources.java
  jarresources.java
• jars
  http://www.javasoft.com/products/jdk/1.1/docs/guide/jar/index.html
• 有关 java 的归档支持的详细信息，请参阅 "java tip 21: use archive files to speed up applet loading"
  http://www.javaworld.com/javatips/jw-javatip21.html

注释：directdraw®是微软directx® sdk的一个组成部分。java版的directx包含在java 2.0 sdk中。java中通过同directx一起安装的com.ms.directx包中的一套类访问directdraw。

介绍

本文将探讨用于java的directdraw sdk的一些优点、结构和使用。过去，使用动画的程序需要用c++编写（或者汇编语言），原因是动画需要很快的处理速度。动画是通过快速连续地显示一系列画面（或者叫做帧）实现的。为了使用户观看动画时没有闪烁感，至少需要达到每秒12帧的速率。更高的帧速率会产生更平滑的动画：例如，动画片的帧速率通常为每秒24帧。要达到最低的每秒12帧要求，在640´480，256色模式下每秒需要处理3.6m字节的图象数据。处理如此数量的视频数据是非常困难的。directdraw现在为java开发人员提供了这种视频数据处理能力。

开始使用directdraw api需要一些基本步骤。现将其列举如下，并且将会在后面的部分中解释：

1. 创建directdraw对象。
2. 设置协作级别。
3. 创建需要的表面。
4. 装入需要的位图。
5. 显示表面。

directdraw对象

要在java中使用directdraw，必须先创建directdraw对象：

        dd = new directdraw();

一旦创建了directdraw对象，就需要设置协作级别。

协作级别

必须要设置directdraw在最高层窗口上拥有的控制级别。在最简单的级别上，directdraw的功能同其他程序相同，限制在windows® 95或者windows nt®窗口内。这是directdraw的正常级别操作。正常协作级别可以通过下面的语句设置：

dd.setcooperativelevel(hwnd, ddscl_normal);

注意   为了使程序能够利用更高级的directdraw特性，如改变显示模式或者修改directdraw的表面的行为，需要使用独占模式。然而，使用高级特性超出了本文的范围。要得到关于使用高级特性的更多信息，请参考directx文档。

创建表面

directdraw使用术语表面（surface）代表显示内容。表面既可以放在显示内存中，也可以放在系统内存中。然而，如果显示硬件没有足够的内存存放表面，directdraw会在系统内存中模拟表面。directdraw表面的最大优点是它总是以线性内存区域的形式提供给开发者。即使程序设置的显示模式不是线性的，表面为开发者提供的仍然是线性内存区域。考虑下面的例子，modex中显示内存是以一系列位面（plane）配置的（图1）。为了画一个点，必须防卫适当的内存位面以及正确的地址。directdrawsurface对象处理了所有这些细节。

图 1. mode x中的显示内存组织。

一个directdraw表面可以包含多个内存缓冲区，允许构建可以切换的表面。切换表面使程序可以利用双缓冲技术的优点。在双缓冲方法中，程序在后台缓冲区中绘制一些内容，画完后，快速地将后台缓冲区切换或者复制到前台缓冲区，使该画面显示出来。双缓冲方法速度非常快，尤其是当前台和后台缓冲区都在显示内存中时。此时，切换操作甚至不消耗任何cpu时间。

基于directdraw程序的用户看到的总是原始表面（primary surface）。为了改变用户看到的内容，可以简单地改变原始表面的内容。通常，需要创建一个或多个后台表面，这些表面中包含不同时间显示的画面。图2说明了一个复杂的双缓冲原始表面。该原始表面由一个后台缓冲区、一个前台缓冲区和四个后台表面组成。每个后台表面包含一个不同旋转阶段的位图。要使圆柱体动起来，程序将每个位图从后台表面中复制到原始表面的后台缓冲区中的一个位置。每当每个圆柱体的复制完成时，程序将后台缓冲区切换到前台缓冲区。

图2. 双缓冲表面之间的关系

directdraw在java中的实现包括两个为表面工作而特别设计的类。ddsurfacedesc类用来描述所创建表面的属性。directdrawsurface类包含为directdraw表面工作所做的定义、方法和变量。

要创建directdraw表面，不管是原始表面还是后台表面，必须先创建ddsurfacedesc对象，设置表面属性，并且把表面描述结构传递给directdraw对象的createsurface()方法。下面的语句创建了一个由一个缓冲区组成的原始表面：

// create a primary surface containing a single buffer.

ddsd = new ddsurfacedesc();

ddsd.flags = ddsd_caps ;

ddsd.ddscaps = ddscaps_primarysurface;

pdds = dd.createsurface( ddsd );

下面的语句创建了一个双缓冲原始表面：

//create a primary surface containing a back //buffer for double buffering.

ddsd = new ddsurfacedesc();

ddsd.flags = ddsd_caps | ddsd_backbuffercount;

ddsd.ddscaps = ddscaps_primarysurface | ddscpas_flip | ddscaps_complex;

ddsd. backbuffercount = 1;

pdds = dd.createsurface( ddsd );

下面的语句说明了如何创建一个320象素宽200行高的后台表面：

ddsd = new ddsurfacedesc();

ddsd.flags = ddsd_caps | ddsd_height | ddsd_width;

ddsd.ddscaps = ddscaps_offscreenplain;

ddsd.width = 320;

ddsd.height = 200;

pdds = dd.createsurface( ddsd );

将位图装入到directdraw表面中

位图是程序可以用来显示图形内容的图片。图2中的四个圆柱体每一个都是一张位图。java中的directdraw为操作位图文件提供了directdrawbitmap类。directdrawbitmap对象创建后，可以复制到directdraw表面。下面的语句将一个叫作frntback.bmp的位图文件读入到directdraw表面：

//read the bitmap file.

bm =  new directdrawbitmap();

bm.filename(“frntback.bmp”);

bm.initwidth(dx);

bm.initheight(dy);

if( bm.loaded() != 0 )

{

    // create a directdrawsurface for

    // this bitmap.

    ddsd = new ddsurfacedesc();

    ddsd.flags = ddsd_caps |

    ddsd_height | ddsd_width;

    ddsd.ddscaps = ddscaps_offscreenplain;

    ddsd.width = bm.width();

    ddsd.height = bm.height();

    pdds = dd.createsurface( ddsd );

    pdds.copybitmap(bm, 0, 0, 0, 0);

}

//off-screen surface pdds now contains the

//bitmap data.

显示表面

当所有表面都创建并初始化（例如将位图复制到表面中）以后，程序需要显示它们时就可以将它们复制到原始表面。这种表面复制通过directdrawsurface对象的blt方法完成。在缺省的操作模式下，如果切换程序忙（正在进行切换），dds.blt()方法立即返回一个错误码。因此，应该以某种循环的形式使用dds.blt()方法，或者指定dds.blt()方法的ddblt_wait标志。第二个选项改变了dds.blt()的行为，使得此方法等待，直到切换可以进行或者出现另一个错误。

下面的代码说明了如何使用directdrawsurface的blt方法。首先，有两点需要阐明。如果显示卡的模式改变或者程序使用对显示卡的独占访问而释放了当前在显卡上分配的所有表面内存，directdrawsurface就会丢失。当表面丢失时，需要恢复。恢复可以通过两个步骤完成。首先调用directdrawsurface对象的restore方法重新分配表面内存以及重新添加directdrawsurface对象。然后，重建相关表面的内容。

rc.left   = 0;

rc.top    = 0;

rc.right  = bm.width();

rc.bottom = bm.height();

// show the off-screen surface on the

//primary surface.

done = 0;

do

{

   int retval;

   retval = ddsprimary.blt( rc, ddsone, rc, 0);

   if( retval == dd_ok )

    {

        //if the bitmap has been successfully

        //copied, exit loop.

        done = 1;

    }

    else if ( retval == dderr_surfacelost )

    {

        while( ddsprimary.restore() != dd_ok &&

            ddsone.restore() != dd_ok )

        {

            reloadbitmap(ddsone, szbitmap);

        }

    }

    else if( retval != dderr_wasstilldrawing)

    {

        // undetermined error; quit the loop.

        done = 1;

    }

} while( done == 0);

其他信息

本文提供了初始化和使用java中directdraw sdk的背景和基本步骤。要获得java的directx sdk以及相关文档，可以从http://www.microsoft.com/java/下载microsoft sdk for java 2.0（其中包含directx sdk）。其中还包括几个示例程序，对于使用directx for java创建动画非常有用。这些例子列举如下：