深入Java调试体系: 第1部分，JPDA体系概览

JPDA（Java Platform Debugger Architecture）是 Java 平台调试体系结构的缩写 通过 JPDA 提供的 API 开发人员可以方便灵活的搭建 Java 调试应用程序 JPDA 主要由三个部分组成 Java 虚拟机工具接口（JVMTI） Java 调试线协议（JDWP） 以及 Java 调试接口（JDI） 本系列将会详细介绍这三个模块的内部细节 通过实例为读者揭开 JPDA 的面纱 本文是该系列的第一篇 将会着重从整体上介绍 JPDA 的各个组成 阐述它们彼此之间的内在关联

JPDA 概述

所有的程序员都会遇到 bug 对于运行态的错误 我们往往需要一些方法来观察和测试运行态中的环境 在 Java 程序中 最简单的 您是否尝试过使用 System out println（） 来输出您的 Java 程序的执行中的各种变量状态来发现您的 Java 程序运行时的问题？这种方式方便易用 在一些简单的情况下能够解决您的问题 但是如果当您的程序运行在远程环境上 或者当前环境不允许控制台终端输出（比如 考虑一下虚拟机初始化之时） 您无法获取终端输出的时候呢？或者 如果您根本无法本地修改运行您的程序？

无须担心 您可以通过很多的调试工具来帮助您解决这个问题 常见的 IDE 都附带一个非常直观简单的调试工具 比如 Eclipse（图 ）就提供一个功能非常全面 *** 作非常简单的调试器

图 使用 Eclipse 调试 Java 程序

其他的一些常见的 Java IDE 比如 Netbeans 和 IntelliJ 等等也都提供了类似的功能 您甚至能不用 IDE 提供的图形界面 使用 JDK 自带的 jdb 工具 以文本命令的形式来调试您的 Java 程序 这些形形 *** 的调试器都支持本地和远程的程序调试 那么它们是如何被开发的？它们之间存在着什么样的联系呢？我们不得不提及 Java 的调试体系—— JPDA

我们知道 Java 程序都是运行在 Java 虚拟机上的 我们要调试 Java 程序 事实上就需要向 Java 虚拟机请求当前运行态的状态 并对虚拟机发出一定的指令 设置一些回调等等 那么 Java 的调试体系 就是虚拟机的一整套用于调试的工具和接口

对于 Java 虚拟机接口熟悉的人来说 您一定还记得 Java 提供了两个接口体系 JVMPI（Java Virtual Machine Profiler Interface）和 JVMDI（Java Virtual Machine Debug Interface） 而它们 以及在 Java SE 中准备代替它们的 JVMTI（Java Virtual Machine Tool Interface） 都是 Java 平台调试体系（Java Platform Debugger Architecture JPDA）的重要组成部分 Java SE 自 版就开始推出 Java 平台调试体系结构（JPDA）工具集 而从 JDK x 开始 Java SDK 就提供了对 Java 平台调试体系结构的直接支持 顾名思义 这个体系为开发人员提供了一整套用于调试 Java 程序的 API 是一套用于开发 Java 调试工具的接口和协议 本质上说 它是我们通向虚拟机 考察虚拟机运行态的一个通道 一套工具 理解这一点对于学习 JPDA 非常重要

换句话说 通过 JPDA 这套接口 我们就可以开发自己的调试工具 通过这些 JPDA 提供的接口和协议 调试器开发人员就能根据特定开发者的需求 扩展定制 Java 调试应用程序 开发出吸引开发人员使用的调试工具 前面我们提到的 IDE 调试工具都是基于 JPDA 体系开发的 区别仅仅在于它们可能提供了不同的图形界面 具有一些不同的自定义功能 另外 我们要注意的是 JPDA 是一套标准 任何的 JDK 实现都必须完成这个标准 因此 通过 JPDA 开发出来的调试工具先天具有跨平台 不依赖虚拟机实现 JDK 版本无关等移植优点 因此大部分的调试工具都是基于这个体系的

JPDA 组成模块

JPDA 定义了一个完整独立的体系 它由三个相对独立的层次共同组成 而且规定了它们三者之间的交互方式 或者说定义了它们通信的接口 这三个层次由低到高分别是 Java 虚拟机工具接口（JVMTI） Java 调试线协议（JDWP）以及 Java 调试接口（JDI） 这三个模块把调试过程分解成几个很自然的概念 调试者（debugger）和被调试者（debuggee） 以及他们中间的通信器 被调试者运行于我们想调试的 Java 虚拟机之上 它可以通过 JVMTI 这个标准接口 监控当前虚拟机的信息 调试者定义了用户可使用的调试接口 通过这些接口 用户可以对被调试虚拟机发送调试命令 同时调试者接受并显示调试结果 在调试者和被调试着之间 调试命令和调试结果 都是通过 JDWP 的通讯协议传输的 所有的命令被封装成 JDWP 命令包 通过传输层发送给被调试者 被调试者接收到 JDWP 命令包后 解析这个命令并转化为 JVMTI 的调用 在被调试者上运行 类似的 JVMTI 的运行结果 被格式化成 JDWP 数据包 发送给调试者并返回给 JDI 调用 而调试器开发人员就是通过 JDI 得到数据 发出指令 图 展示了这个过程

图 JPDA 模块层次

当然 开发人员完全可以不使用完整的三个层次 而是基于其中的某一个层次开发自己的应用 比如您完全可以仅仅依靠通过 JVMTI 函数开发一个调试工具 而不使用 JDWP 和 JDI 只使用自己的通讯和命令接口 当然 除非是有特殊的需求 利用已有的实现会使您事半功倍 避免重复发明轮子

这三个模块我们会在后续文章中分别详细介绍 这里我们简单介绍它们的主要功能

Java 虚拟机工具接口（JVMTI）

JVMTI（Java Virtual Machine Tool Interface）即指 Java 虚拟机工具接口 它是一套由虚拟机直接提供的 native 接口 它处于整个 JPDA 体系的最底层 所有调试功能本质上都需要通过 JVMTI 来提供 通过这些接口 开发人员不仅调试在该虚拟机上运行的 Java 程序 还能查看它们运行的状态 设置回调函数 控制某些环境变量 从而优化程序性能 我们知道 JVMTI 的前身是 JVMDI 和 JVMPI 它们原来分别被用于提供调试 Java 程序以及 Java 程序调节性能的功能 在 J SE 之后 JDK 取代了 JVMDI 和 JVMPI 这两套接口 JVMDI 在最新的 Java SE 中已经不提供支持 而 JVMPI 也计划在 Java SE 后被彻底取代

Java 调试线协议（JDWP）

JDWP（Java Debug Wire Protocol）是一个为 Java 调试而设计的一个通讯交互协议 它定义了调试器和被调试程序之间传递的信息的格式 在 JPDA 体系中 作为前端（front end）的调试者（debugger）进程和后端（back end）的被调试程序（debuggee）进程之间的交互数据的格式就是由 JDWP 来描述的 它详细完整地定义了请求命令 回应数据和错误代码 保证了前端和后端的 JVMTI 和 JDI 的通信通畅 比如在 Sun 公司提供的实现中 它提供了一个名为 jdwp dll（jdwp so）的动态链接库文件 这个动态库文件实现了一个 Agent 它会负责解析前端发出的请求或者命令 并将其转化为 JVMTI 调用 然后将 JVMTI 函数的返回值封装成 JDWP 数据发还给后端

另外 这里需要注意的是 JDWP 本身并不包括传输层的实现 传输层需要独立实现 但是 JDWP 包括了和传输层交互的严格的定义 就是说 JDWP 协议虽然不规定我们是通过 EMS 还是快递运送货物的 但是它规定了我们传送的货物的摆放的方式 在 Sun 公司提供的 JDK 中 在传输层上 它提供了 socket 方式 以及在 Windows 上的 shared memory 方式 当然 传输层本身无非就是本机内进程间通信方式和远端通信方式 用户有兴趣也可以按 JDWP 的标准自己实现

Java 调试接口（JDI）

JDI（Java Debug Interface）是三个模块中最高层的接口 在多数的 JDK 中 它是由 Java 语言实现的 JDI 由针对前端定义的接口组成 通过它 调试工具开发人员就能通过前端虚拟机上的调试器来远程 *** 控后端虚拟机上被调试程序的运行 JDI 不仅能帮助开发人员格式化 JDWP 数据 而且还能为 JDWP 数据传输提供队列 缓存等优化服务 从理论上说 开发人员只需使用 JDWP 和 JVMTI 即可支持跨平台的远程调试 但是直接编写 JDWP 程序费时费力 而且效率不高 因此基于 Java 的 JDI 层的引入 简化了 *** 作 提高了开发人员开发调试程序的效率

表 总结了三个模块的不同点

表 JPDA 层次比较 模块 层次 编程语言 作用 JVMTI 底层 C 获取及控制当前虚拟机状态 JDWP 中介层 C 定义 JVMTI 和 JDI 交互的数据格式 JDI 高层 Java 提供 Java API 来远程控制被调试虚拟机

JPDA 实现

关于 Apache Harmony 项目 Apache Harmony 旨在开发出一个独立且与现有 JDK 兼容的 Java SE 实现 它以 Apache 软件许可证 版发行 它建立了一个开放的模块化运行时架构 包括虚拟机和类库之间及其内部的模块化 通过这个平台 社区能在已有实现的基础上自由定制自己的 Java 实现 或者对某个模块单独进行创新

每一个虚拟机都应该实现 JVMTI 接口 但是 JDWP 和 JDI 本身与虚拟机并非是不可分的 这三个层之间是通过标准所定义的交互的接口和协议联系起来的 因此它们可以被独立替换或取代 但不会影响到整体调试工具的开发和使用 因此 开发和使用自己的 JDWP 和 JDI 接口实现是可能的

Java 软件开发包（SDK）标准版里提供了 JPDA 三个层次的标准实现 事实上 调试工具开发人员还有很多其他开源实现可以选择 比如 Apache Harmony 提供了 JDWP 的实现 而 JDI 我们可以在 Eclipse 一个子项目 eclipse jdt debug 里找到其完整的实现（Harmony 也使用了这套实现 作为其 J SE 类库的一部分） 通过标准协议 Eclipse IDE 的调试工具就可以完全在 Harmony 的环境上运行

Java 调试接口的特点

Java 语言是第一个使用虚拟机概念的流行的编程语言 正是因为虚拟机的存在 使很多事情变得简单而轻松 掌握了虚拟机 就掌握了内存分配 线程管理 即时优化等等运行态 同样的 Java 调试的本质 就是和虚拟机打交道 通过 *** 作虚拟机来达到观察调试我们自己代码的目的 这个特点决定了 Java 调试接口和以前其他编程语言的巨大区别

以C/C++ 的调试为例 目前比较流行的调试工具是 GDB 和微软的 Visual Studio 自带的 debugger 在这种 debugger 中 首先 我们必须编译一个 debug 模式的程序 这个会比实际的 release 模式程序大很多 其次 在调试过程中 debugger 将会深层接入程序的运行 掌握和控制运行态的一些信息 并将这些信息及时返回 这种介入对运行的效率和内存占用都有一定的需求 基于这些需求 这些 Debugger 本身事实上是提供了 或者说 创建和管理了一个运行态 因此他们的程序算法比较复杂 个头都比较大 对于远端的调试 GDB 也没有很好的默认实现 当然 C/C++ 在这方面也没有特别大的需求

而Java 则不同 由于 Java 的运行态已经被虚拟机所很好地管理 因此作为 Java 的 Debugger 无需再自己创造一个可控的运行态 而仅仅需要去 *** 作虚拟机就可以了 Java 的 JPDA 就是一套为调试和优化服务的虚拟机的 *** 作工具 其中 JVMTI 是整合在虚拟机中的接口 JDWP 是一个通讯层 而 JDI 是前端为开发人员准备好的工具和运行库

从构架上说 我们可以把 JPDA 看作成是一个 C/S 体系结构的应用 在这个构架下 我们可以方便地通过网络 在任意的地点调试另外一个虚拟机上的程序 这个就很好地解决了部署和测试的问题 尤其满足解决了很多网络时代中的开发应用的需求 前端和后端的分离 也方便用户开发适合于自己的调试工具

从效率上看 由于 Java 程序本身就是编译成字节码 运行在虚拟机上的 因此调试前后的程序 内存占用都不会有大变化（仅仅是启动一个 JDWP 所需要的内存） 任意程度都可以很好地调试 非常方便 而 JPDA 构架下的几个组成部分 JDWP 和 JDI 都比较小 主要的工作可以让虚拟机自己完成

从灵活性上 Java 调试工具是建立在强大的虚拟机上的 因此 很多前沿的应用 比如动态编译运行 字节码的实时替换等等 都可以通过对虚拟机的改进而得到实现 随着虚拟机技术的逐步发展和深入 各种不同种类 不同应用领域中虚拟机的出现 各种强大的功能的加入 给我们的调试工具也带来很多新的应用

总而言之 一个先天的 可控的运行态给 Java 的调试工作 给 Java 调试接口带来了极大的优势和便利 通过 JPDA 这个标准 我们可以从虚拟机中得到我们所需要的信息 完成我们所希望的 *** 作 更好地开发我们的程序

结束语

lishixinzhi/Article/program/Java/JSP/201311/19143

什么是JPDA

Java Platform Debugger Architecture(JPDA:Java平台调试架构) 由Java虚拟机后端和调试平台前端组成

1.Java虚拟机提供了Java调试的功能

2.调试平台通过调试交互协议向Java虚拟机请求服务以对在虚拟机中运行的程序进行调试

JPDA的构架

JPDA通过两个接口和协议来完成如上的说明，分别是JVMTI（Java虚拟机工具接口）、JDWP（Java调试连线协议）和JDI（Java调试接口）。

1.JVMTI定义了虚拟机应该提供的调试服务，包括调试信息（Information譬如栈信息）、调试行为（Action譬如客户端设置一个断点）和通知（Notification譬如到达某个断点时通知客户端），该接口由虚拟机实现者提供实现，并结合在虚拟机中

2.JDWP定义调试服务和调试器之间的通信，包括定义调试信息格式和调试请求机制

3.JDI在语言的高层次上定义了调试者可以使用的调试接口以能方便地与远程的调试服务进行交互，Java语言实现，调试器实现者可直接使用该接口访问虚拟机调试服务。

我是从“上海全鼎软件学院”毕业的————————

充分利用 J2EE 调试工具--Java 开发环境的增强功能有助于调试J2EE 应用程序

我的第一个 Java 项目包括接管由我所在公司的一个部门编写的一个门户，该部门现在已经关闭了。当我凝视着运行门户代码的服务器终端时，我看到一行接一行的调试代码涌现在在屏幕上。进一步的研究之后，我发现 JavaServer Pages （ JSP ）和 servlet 中到处都是 System.out.println （“ [Debug Statement] ”）。由于我对我接管的语言和代码有些陌生，我坚持自己为终端编写调试语句，因为我不知道调试 Java 代码的其他方法。

然而，在漫长而乏味的调试过程中，我不断失败。我发现在将代码提交给 QA 之前很难移除所有的调试语句。同样，调试涉及到重新编译、重新部署的代码和在执行代码时观察终端也非常困难。为了查找代码中断的点，我时常在方法中的每一行代码后加入 println 语句，在这种情况下，过程常常为找到的每一个故障重复。

最后，在我发现 Java 平台调试架构（ Java Platform Debugger Architecture ， JPDA ）的时候，我摆脱了调试梦魇。 JPDA 是一套组成构建调试应用程序框架的 API 。幸运的是，我们大多数人不需要自己考虑创建调试应用程序的事，因为这些是与主要的 IDE 捆绑在一起提供的。调试在这些新的 IDE 中是一个相当简单和轻松的过程。

您必须执行几个步骤才可以使您的开发环境成为您可以进行调试的环境。如果您正在使用 Sun 的 Java Virtual Machine （ JVM ）进行调试，您必须在命令行中指定启动 J2EE 容器的时间，其中， JVM 已经以调试模式启动。为了执行该 *** 作，只需在 java 命令的后边添加 -Xdebug 参数。我们随后将研究一个命令行调试参数的示例。为了加载 Java Debug Wire Protocol ( JDWP ) 的 JPDA 参数实现，需要使用具有随后指定的 JPDA 选项的 -Xrunjdwp 。该参数加载进行中的调试资料库，而其子选项提供了调试服务器如何与调试客户端交互的细节。我们将研究一份 JPDA 子选项列表，该列表可以帮助设置正确的调试环境。

首先，指定传输选项。 transport 用于在调试程序和 VM 使用的进程之间通讯。 Win32 平台的 VM 提供了很多其他平台使用的共享内存传输和套接字传输。共享的内存传输（仅在 Win32 平台中受支持）要求调试应用程序和目标 VM 存放在相同的机器中。套接字传输使用标准的 TCP/IP 套接字来与调试信息通信。调试客户端和调试服务器可以位于使用套接字传输的相同或者不同的机器中。对于远程调试 Enterprise JavaBeans （ EJB ）和 servlet 来说，我们关注于使用套接字传输，因为它受所有平台支持：

transport=dt_socket

我们正在启动的 VM 需要作为调试服务器执行。如前所述，调试服务器是运行以调试模式编译的应用程序的 JVM （以后讲述），并具有允许客户端连接和 监听 应用程序的开放套接字。为了使 VM 成为一台服务器，需要提供服务器选项，并将其值设置为 yes ：

server=yes

接下来，我们需要指出调试服务器将要使用的端口号，同时也是端口客户端用来连接服务器的端口号。只有知道正在运行服务器的端口号的客户端才可以建立连接，因为不存在标准的调试端口，也就是 HTTP 服务器。任何未使用的端口都适用。在我们的情况中，我们使用了端口 4000 ：

address=4000

避免混乱

您可以提供一个选项，仅在调试客户端建立连接之后启动 VM （ suspend=y ）。我的 J2EE 容器具有一种服务，它可以在容器登录之后立即启动，而不用添加 suspend=y 到参数列表。我发现在我的那项服务启动之前，启动客户端并连接到 VM 有些混乱 。使用该选项，我就可以启动 VM 。当它暂停的时候，我打开 IDE ，设置中断点，然后建立调试连接。一旦连接建立，容器继续登录，而我可以一步步启动服务。

onthrow 选项推迟初始化 JDWP 资料库，直到引发指定类的异常。例如，如果需要在引发异常（如 ServletException ）时执行一些 *** 作，您需要包含如下选项：

onthrow=

javax.servlet.ServletException

同样， JDWP 资料库初始化也可以推迟，直到引发异常但没有捕获时，该 *** 作可以通过提供 onuncaught=y 选项指定。

启动选项指出 VM 应当基于调试事件来启动应用程序，该事件与 onthrow 或者 onuncaught 选项一起提供：

launch=/usr/home/mydir/debugapp

让我们研究一些我经常使用的命令行调试参数的示例。在第一个示例中，我们将指导 VM 使用套接字传输。调用的 VM 是服务器，它应当监听端口 4000 。我们还指出 VM 应当在调试服务器建立连接后才可以暂停：

-Xrunjdwp:transport=

dt_socket,server=y,address=4000,

suspend=n

第二套参数类似于前一个示例，不同的是其传输现在是一种共享内存传输（仅限于 Windows ）：

-X runjdwp:transport=

dt_shmem,server=y,address=4000,

suspend=n

第三套参数会导致 VM 通过端口 4000 上的套接字连接附加到正在运行中的调试服务器中，这将要求 VM 以调试模式运行在端口 4000 上的 SomeHost 中：

-X runjdwp:transport=

dt_socket,server=n,address=

SomeHost:4000, suspend=n

第四套参数将导致 VM 在开始的时候暂停。 VM 将等待建立与调试客户端的连接，然后再继续加载。 VM 使用端口 4000 来监听客户端，并使用套接字连接：

-X runjdwp:transport=

dt_socket,server=y,address=

4000, suspend=y

使用第五套参数，当引发 javax.management.InstanceNotFoundException 的时候， VM 将暂停，并启动 c:\debug.bat 。 debug.bat 脚本可以启动调试应用程序，该应用程序可以连接服务器，并开始调试会话：

-Xrunjdwp:transport=

dt_socket,address=4000,server=

y,suspend=y,onthrow=

javax.management.

InstanceNotFoundException,

launch=c:\debug.bat

最后一套参数将在引发异常但没有捕获的时候执行 debug.bat 脚本：

-Xrunjdwp:transport=

dt_socket,address=4000,server=

y,suspend=n,onuncaught=

y,launch=c:\debug.bat

我们现在可以使用一些现有的通用 IDE 来说明如何调试 J2EE 。我们在示例中使用的 J2EE 容器是 JBoss 服务器；然而，任何标准的 J2EE 容器都是可用的。 JBoss 服务器从 bin 目录中的 run.bat 文件启动。 BAT 文件可以接受调试命令行自变量，并将它们发送给 JVM 。作为一名开发人员，我发现我很少需要启动开发环境（除了调试模式），因此我将 run.bat 复制到一个名叫 debug.bat 的新文件中，并且在该文件中添加了调试参数。以下是 JBoss debug.bat 文件的内容：

rem Read all command line

rem arguments

set ARGS=

:loop

if [%1] == [] goto endloop

set ARGS=%ARGS% %1

shift

goto loop

:endloop

set JAVA_OPTS=

-Dprogram.name=run.bat

set JAVAC_JAR=

%JAVA_HOME%\lib\tools.jar

set RUNJAR=.\run.jar

set JBOSS_CLASSPATH=

%JBOSS_CLASSPATH%%JAVAC_JAR%

%RUNJAR%

rem Set the debug options here

set DEBUG_OPTS =

-Xdebug -Xnoagent

-Djava.compiler=

NONE -Xrunjdwp:transport=

dt_socket,address=

4000,server=y,suspend=n

Java %JAVA_OPTS% %DEBUG_OPTS%

-classpath "%JBOSS_CLASSPATH%"

org.jboss.Main %ARGS%

调试信息

在将 IDE 的调试程序连接到服务器之前，将应用程序放在服务器上。确保使用打开的调试信息对应用程序进行编译。这样做可以在已经编译的类文件中提供行编号方式。如果您使用 Ant 来构建项目，请确保 javac 任务包含：

debug="on"

否则， IDE 应当包含在编译期间打开调试的选项。

我提供了 从简单的 DocBook 文件生成 PDF E-Books 的 J2EE 应用程序 。该应用程序由会话 bean 、 JSP 文件和 servlet 组成。会话 bean 可以列举存储在服务器中的 DocBook 文档和 XSL 样式表文件。 JSP 使用会话 bean 来显示书籍和 XSL 文件的列表，以下拉列表的方式显示。用户可以选择他们要将哪些文件转换成 PDF ，并指定要将哪些样式表用于转换。作为最后一个步骤， servlet 将 DocBook 文件转换为 PDF ，并将 PDF 显示在用户的 Web 浏览器中。 Apache 的 FOP 资料库用于转换文档（参阅 资源 ）。

如果您想使用我构建的应用程序，请编辑 Ebook.properties 文件，并提供到您的机器中某个位置的有效路径，该位置中存放 DocBook 和 XSL 文件。示例 DocBook 和 XSL 文件还可以下载。请将这些文件存放在您指定的位置中。

我已经提供了一份 Ant build.xml 文件来构建应用程序和将类封装到企业归档文件（ EAR ）中。将 EAR 文件部署到 JBoss 的目录中，并启动具有以下参数的容器：

-Xrunjdwp:transport=

dt_socket,server=y,address=4000,

suspend=n

现在，我们已经准备好在调试模式中连接代码

Intelli-J IDEA 调试

为了在Intelli-J中连接调试服务器，只需点击工具条中的Debug按钮，打开调试配置界面即可。然后选择Remote标记，来查看哪些调试配置可用。最初，没有配置可以使用。点击屏幕左上方的+按钮来添加新的远程调试配置。输入主机名称或者IP地址和要连接到的端口（参见图1）。

图 1. 远程 Intelli-J 调试

图中有一个 Intelli-J 中的连接到本地机器的远程调试配置。

确保服务器启动时具有已经为 VM 进行设置的调试选项，然后点击 Debug 按钮。您应当连接到 VM ，并且您的调试屏幕中将出现在 Intelli-J 屏幕的底部。您可以通过点击 Edit 窗口右边空白区域来轻松的在 IDE 中设置中断点。在中断的地方会出现一个红点。如果圆点中有一个 X ，则您指定的中断点无效，或者服务器中的代码在编译时没有打开调试。如果圆点中有一个校验标记，则说明您已经成功的连接到调试服务器，和已经选择了有效的中断点位置。您可以进行调试了。如果您使用的是本文提供的 示例代码 ，则请在 EJB 的 getDocBooks() 方法中设置中断点。将 Web 浏览器指向 http://localhost:8080/DocBookToPDF/DocBook.jsp 。您的浏览器应当显示为悬挂状态，并且 Intelli-J 在设置中断点的行中应当有一个蓝条。恭喜，您正在调试 EJB ，您的 IDE 已经为进入代码准备就绪（参见 图 2）。

图 2. Intelli-J 中断点

Intelli-J 中断点在其设置的地方以蓝色突出显示。图中，中断点已经设置，可以进行下一步骤。

们正在调试的方法查找在 DocBookToPDF.properties 文件中指定的目录，并返回所有以 XML 为结尾的文件。该方法假设每一个文档都是 DocBook 文件。在我们继续之前，确保目录具有有效的 DocBook 和 XSL 文件，以将文档转换为 PDF 。

完成进入代码之后，注意 JSP 在下拉列表中显示 DocBook 和 XSL 文件。下一步骤是调试 DocBookToPDFServlet servlet 。将中断点放在 Edit 窗口左边， processRequest() 方法中的某个位置。在 Web 浏览器中选择 DocBook 文件和有效的 XSL 文件，然后点击 Web 页面中的 Generate Book 按钮。 servlet 中的中断点将呈现为蓝色， servlet 代码可以进入。

NetBeans/Forte 调试

在 NetBeans 中创建一个项目，该项目包含您需要调试的代码。使用打开的调试选项编译它，并像在前面 Intelli-J 部分中讨论的那样，将应用程序部署到服务器中。我提供的 Ant build XML 文件演示了如何以调试模式编译代码。

为了开始调试，请选择 Debug | Start Session | Attach 菜单选项。这时，将出现一个对话框，要求填写连接信息。指定 JPDA 为调试程序， SocketAttach 为连接程序， localhost 为主机，端口 4000 为要连接到的器。点击 OK 按钮，您应当附加到 J2EE 容器的 VM （参见 图 3 ）中。 Debug 窗口将成为活动窗口，您现在可以使用相同的方式来设置中断点，就像使用 Intelli-J 那样。在 EJB 的 getDocBooks() 方法中设置中断点，并将 Web 浏览器指向 http://localhost:8080/DocBookToPDF/DocBook.jsp 。 Web 页面应当显示为悬挂状态，而 NetBeans 中的中断点将被突出显示（参见 图 4 ）。您可以在 IDE 中点击调试工具栏中的 Step Over 和 Step Into 按钮来进入 NetBeans 中的代码。您还可以在界面左边框架中设置观察。

图 3. 远程 NetBeans 调试

图中是 NetBeans 中本地机器的远程调试配置

图 4. NetBeans 中断点

NetBeans 中断点在活动状态时以绿色突出显示。图中是已经设置的中断点，已经准备好进行调试。

为了调试 servlet ，请在 processRequest() 方法中设置中断点。当 JSP 在 Web 浏览器中完成加载，并在机器中显示 DocBooks 和 XSL 文件的列表之后，选择 DocBook 文件和 XSL 文件，然后点击 Web 页面中的 Generate Book 按钮。在 NetBeans 中，中断点将变为突出显示状态，您可以开始调试 servlet 代码了。

Eclipse

为了在Eclipse中调试，需要在Java透视图中创建一个项目。如果您正在使用DocBook-to-PDF代码示例，则使用Ant build.xml编译代码，以编译打开调试的类。突出显示Java应用程序，并选择Run | Debug菜单项。此时，将出现一个对话框。突出显示Remote Java Application，然后点击对话框左手边底部的New按钮。对话框项目的名称应当为在Java透视图中突出显示的项目的名称。对话框中连接部分的主机字段应当是您需要连接到的服务器，端口字段中应当具有容器的VM正在使用的调试端口（参见图5）

图 5. 远程 Eclipse 调试

图中是 Eclipse 中本地机器的远程调试配置。

接下来，点击Debug按钮。Eclipse将转到Debug透视图。为了调试代码，请返回到Java透视图中，并在编辑器中打开EJB文件或者servlet。双击EJB的getDocBooks()方法的左手边的窗格来设置一个中断点。有效的中断点具有一个蓝色的圆球，并且圆球中有一个校验标记。如果中断点中没有校验标记，双击该中断点，然后尝试不同的点。

接下来，将Web浏览器指向相同的JSP和servlet文件，就像前面NetBeans和Intelli-J中所描述的那样。当设置中断点时，中断点所在的行将被突出显示，您可以像使用其他IDE那样来调试代码（参见图6）。

图 6. Eclipse 中断点

Eclipse 中有效的中断点以蓝色圆球和校验标记指示。该图说明了如何在 Eclipse IDE 中调试代码。当前的调试位置以绿色突出显示

使用具有流行 IDE 的 JPDA 资料库应当会缩短开发时间，并且允许您创建包含极少缺陷的更优秀的代码。如果您仍在代码中添加 System.out.println() 语句，以发现程序失败或者中断的位置，那么请住手！您是在浪费时间和金钱。 Java IDE 已经推出很长时间了，它可以提供功能强大的调试工具。您仅需要对启动 VM 的方法做一些小小的改动，就可以轻松地调试 Java 应用程序了。

---