一、Findbugs
1. 配置
1.1 打开FindBugs视图：
Windows => Show View => Other… => FindBugs => Bug Info 、Bug Explorer、Bug Reviews
1.2 配置FindBugs
选择你的项目=>右键 => Properties => FindBugs => 选中“Run automatically” => OK
Findbugs各项属性的配置说明：
Enable project specific setting：该项目是否启用自身特殊设置（忽略全局设置）
Run automnaticaly：编译文件时自动运行。
Also on full build：编译工程时自动运行。必须同时勾选Enable project specific setting
Bug类型说明：
Minimum priority to report：根据bug的优先权级别报告bug。
Malicious code vulnerability：恶意代码。
Dodgy code：高危代码。FindBugs团队认为该类型下的问题代码导致bug的可能性很高。
Bad practice：最佳实践反例。这种类别下的代码违反了公认的最佳实践标准，比如某个类实现了equals方法但未实现hashCode方法等。
Correctness：正确性。这种归类下的问题在某种情况下会导致bug，比如错误的强制类型转换等。
Internationalization：国际化。
Performance：性能。潜在性能问题
Security：安全。
Mutithreaded correctness：多线程的正确性。关注于同步和多线程问题。
1.3 Bug设置
2. 使用
2.1 如下图：我们在工程的右键菜单中选择Find bugs的菜单项“Find bugs”。
2.2 当findBugs运行后,就可以在bug Explorer 视图中看到相应的信息,可以双击切换到相应代码 ,就可以对这个代码改进了,如下图：
这时我们就可以找到BUG所在并修改
2.3 查看Bug详细信息
显示详细信息如下：
2.4 过滤bug设置：
2.4.1 首先点击bug行号前的bug标志，进入bug detail视图，记下这个bug的id，如下图的[RCN]
2.4.2 在Bug Explorer窗口中单击“Filter Bugs by Id“
输入Type（RCN）或Pattern（RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE）即可找出相应的bug设置
ok确认即可。
2.5 分组查看
选择相应的分组依据
或者直接如下图所示分组。
二、Checkstyle
1. 配置
当Checkstyle成功安装后，在"window->Preferences"中可以看到checkstyle的选项， 如图所示：
Checkstyle有两个渠道可以进行配置，一个是全局的，一个是单个项目(Project)的。全局的可以 在整个MyEclipse的workspace中生效， 而单个项目的配置可以在指定的项目中生效，它优先于全局 的配置。
对于单个项目：右键点某个项目，然后选择"Properties"就可以看到 Checkstyle的窗口。在"Main"标签中，"Checkstyle active for this project"前面打勾， 然后在"Simple –use the following check configuration for all files" 下拉框中选择你的Checkstyle配置文件就可以了。如图：
对于全局的设置："window->preferences"就可以看到。设置方法跟单个项目的设置是一样的。
经过上面的设置，Checkstyle就可以使用了。Checkstyle默认提供了基于Sun的检查配置文件，并不一定适合每个公司，因此提供了自定义检查模式。在全局设置中"Global Check Configurations"中单击"New"按钮。
起好名字后，单击"Import"按钮，选择文件后，确定即可。
另外，官方帮助可以在MyEclipse的"Help-> HelpeContents"中的" Checkstyle Plug-in " 中找到。内容还是很详尽的。
2. 使用
很简单，在项目设置中勾选Checkstyle active for this project后，重新编译即可。或者右击项目"Checkstyle -> Check Code with Checkstyle"。
三、JDepend
1. 使用
运行方法是右键选择需要分析的包，选择 Run JDepend Analysis
于是会出现如下分析结果
2. 说明
JDepend为每个Package自动生成的依赖性度量指标，包括：
Number of Classes and Interfaces(CC)：实现类与抽象接口的数目
面向的设计原则之一The Stable Abstractions Principle (SAP)：稳定抽象等价原则指出了包的稳定程度与它的抽象程度（接口的数目）成正比，也就是说，一个包内包含的接口所占的比重越大，这个包就越稳定。
Afferent Couplings (Ca)：向心耦合。依赖该包（包含的类）的外部包（类）的数目（i.e. incoming dependencies），该数值越大，说明该包的担当的职责越大，也就越稳定。
Efferent Couplings (Ce)：离心耦合。被该包依赖的外部包的数目（i.e. outgoing dependencies），该数值越大，说明该包越不独立（因为依赖了别的包），也越不稳定。
Abstractness (A)：包的抽象度。指一个包内包含的抽象类或接口占整个包中的类的比重。该值处于0，1之间，若A=0，说明包内不包含任何抽象类或接口；若A=1,说明包内全部是抽象类或接口。包的抽象度与稳定性之间的关系上面已经作了说明。
Instability (I)：衡量一个包的不稳定程度。I=Ce/(Ce+Ca)。它的值处于[0，1]之间。I=0时说明包是最稳定的，反之I=1则说明包极不稳定。
Distance from the Main Sequence (D)： 该指标主要用来评价包的抽象程度与稳定程度的平衡关系，它可以用二维直线图 A + I = 1 来表示。D=abs((A + I) - 1)，也就是说D为 一个包的抽象度 + 包的不稳定程度 - 1 的绝对值。一个理想的包是：完全抽象的（A=1），非常稳定的（I=0），这时D=0；或者是：完全具体类构成的包（A=0），非常不稳定的 （I=1），这时同样也有D=0。D=0说明包的抽象程度与稳定程度是平衡的，反之D=1说明包的平衡程度被严重破坏。
Package Dependency Cycles：包的循环依赖度。
面向对象的设计原则之一：The Acyclic Dependencies Principle (ADP) - OO设计的无环依赖原则要求包之间不能有循环依赖关系。
四、Eclemma
1. 配置
如果EclEmma只能测试Java Application的测试覆盖率，那么它相对命令行版本的Emma来说，提供的增强就不多了。相反，EclEmma提供了很多与MyEclipse紧 密结合的功能。它不仅能测试Java Application，还能计算JUnit单元测试，对MyEclipse插件测试的覆盖率。从图中我们可以看到EclEmma目前支持几种类型的程 序。
打开EclEmma运行命令按钮
工具栏右键->Customize Perspective
选择Command Groups Availability->勾选Java Code Coverage->Ok
之后在工具栏就会出现按钮
2. 使用
首先建立一个 HelloWorld 类，其代码如下所示：
- package cn.itkt.hotel;
- public class HelloWorld {
- public static void main(String[] args) {
- int rand = (int) (Math.random() * 100);
- if (rand % 2 == 0) {
- System.out.println("Hello, world! 0");
- } else
- System.out.println("Hello, world! 1");
- int result = rand % 2 == 0 ? rand + rand : rand * rand;
- System.out.println(result);
- }
- }
接下来，我们通过 EclEmma 运行 HelloWorld.main() 函数。
执行完毕之后，我们正在编辑 HelloWorld.java 的窗口将会变成如下所示：
在Java编辑器中，EclEmma用不同的色彩标示了源代码的测试情况。其中，绿色的行表示该 行代码被完整的执行，红色部分表示该行代码根本没有被执行，而黄色的行表明该行代码部分被执行。黄色的行通常出现在单行代码包含分支的情况，例如上图 中16行就显示为黄色。由于程序中有一个随机确定的分支，因此读者的窗口可能与这里稍有不同（11行或者14 行中有且只有一个红色的行）。
除了在源代码编辑窗口直接进行着色之外，EclEmma 还提供了一个单独的视图来统计程序的覆盖测试率。
EclEmma提供的Coverage视图能够分层的显示代码的覆盖测试率，上图中的信息表明我们对HelloWorld的一次运行覆盖了大约68.6%的代码。
想在一次运行中覆盖所有的代码通常比较困难，如果能把多次测试的覆盖数据综合起来进行察看，那么 我们就能更方便的掌握多次测试的测试效果。EclEmma提供了这样的功能。现在，让我们重复数次对HelloWorld的覆盖测试。我们注意到 Coverage视图总是显示最新完成的一次覆盖测试。事实上，EclEmma为我们保存了所有的测试结果。接下来，我们将通过 Coverage视图的工具按钮来结合多次覆盖测试的结果。
当我们多次运行 Coverage 之后，我们可以单击图中所示工具栏按钮。之后，一个对话框将被弹出以供用户选择需要合并的覆盖测试。
在合并完成之后，我们可以观察到 Java 编辑器和 Coverage 视图中都显示了合并之后的结果：
图中，我们可以看到，通过多次运行覆盖测试，最终我们的代码达到了91.4%的测试覆盖率。有趣 的是，图中第三行代码被标记为红色，而此行代码实际上是不可执行的。奥妙在于，我们没有生成任何HelloWorld类的实例，因此缺省构造函数没有被调 用，而EclEmma将这个特殊代码的覆盖状态标记在类声明的第一行。
五、Eclipse Class Decompiler
1. 配置
找到MyEclipse->Window->Preferences->Java->反编译器
上图为Eclipse Class Decompiler的首选项页面，可以选择缺省的反编译器工具，并进行反编译器的基本设置。缺省的反编译工具为JD-Core，JD-Core更为先进一些，支持泛型、Enum、注解等JDK1.5以后才有的新语法。
首选项配置选项：
1.1 重用缓存代码：只会反编译一次，以后每次打开该类文件，都显示的是缓存的反编译代码。
1.2 忽略已存在的源代码：若未选中，则查看Class文件是否已绑定了Java源代码，如果已绑定，则显示Java源代码，如果未绑定，则反编译Class文件。若选中此项，则忽略已绑定的Java源代码，显示反编译结果。
1.3 显示反编译器报告：显示反编译器反编译后生成的数据报告及异常信息。
1.4 使用MyEclipse代码格式化工具：使用Eclipse格式化工具对反编译结果重新格式化排版，反编译整个Jar包时，此操作会消耗一些时间。
1.5 使用MyEclipse成员排序：使用Eclipse成员排序对反编译结果重新格式化排版，反编译整个Jar包时，此操作会消耗大量时间。
1.6 以注释方式输出原始行号信息：如果Class文件包含原始行号信息，则会将行号信息以注释的方式打印到反编译结果中。
1.7 根据行号对齐源代码以便于调试：若选中该项，插件会采用AST工具分析反编译结果，并根据行号信息调整代码顺序，以便于Debug过程中的单步跟踪调试。
1.8 设置类反编译查看器作为缺省的类文件编辑器：默认为选中，将忽略MyEclipse自带的Class Viewer，每次MyEclipse启动后，默认使用本插件提供的类查看器打开Class文件。
配置完后检查class文件默认打开方式，MyEclipse->Window->Preferences->General->Editors->File Associations
我们可以看到class文件的打开方式有两个，类反编译查看器和MyEclipse自带的Class File Viewer，而类反编译查看器是默认的才行。
2. 使用
插件提供了系统菜单，工具栏，当打开了插件提供的类反编译查看器后，会激活菜单和工具栏选项，可以方便的进行首选项配置，切换反编译工具重新反编译，以及导出反编译结果。
类反编译查看器右键菜单包含了MyEclipse自带类查看器右键菜单的全部选项，并增加了一个“导出反编译源代码”菜单项。
打开项目路径下的Class文件，如果设置类反编译查看器为缺省的查看器，直接双击Class文件即可，如果没有设置为缺省查看器，可以使用右键菜单进行查看。
Eclipse Class Decompiler插件也提供了反编译整个Jar文件或者Java包的反编译。该操作支持Package Explorer对包显示布局的操作，如果是平铺模式布局，则导出的源代码不包含子包，如果是层级模式布局，则导出选中的包及其所有的子包。
注意：包的“平铺模式布局”和“层级模式布局”的设置
Debug调试：可以在首选项选中对齐行号进行单步跟踪调试，和普通的包含源代码时的调试操作完全一致，同样的也可以设置断点进行跟踪。
注意：首选项选择“根据对齐行号进行单步跟踪调试”后，必须重新反编译class文件才行，否则还是原来事先编译好的代码，会导致跟踪调试失败。重新编译的方法：1：上面图中菜单栏。2：上面图中类打开方式。