如果很快看一下 JLS 的第 9.1.1 节，会发现 synchronized 在该上下文中不是合法的修饰符。如果尝试使用早期发行版 JDK 中的 Javac 编译器来编译相同的类，则不会生成错误（该错误在稍后的发行版中得到修正）。
| % javac SynchronizedInterface.java |
现在既然问题得以重现，可以通过以下步骤来对 Jacks 测试套件添加回归测试案例：
了解应该将测试案例放在哪个目录中
编写回归测试
在 Jacks 框架中运行新测试
tcltest 框架中回归测试的格式是：
| tcltest::test NAME DESCRIPTION {
COMMANDS } EXPECTED_RESULT |
这是 JLS 第 9.1.1 节中的第一个测试，所以 NAME 是 9.1.1-1。
该测试案例在目录 tests/jls/interfaces/interface-declarations/interface-modifiers （位置基于 JLS 节的名称）中。
DESCRIPTION 可以是任何想要的内容。
COMMANDS 一节包含了所有 Tcl 命令，但大多数情况只需要 Jacks 中的 saveas 和 compile 方法。
saveas 命令使用两个自变量：文件名和将保存到文件中的数据。
| saveas SynchronizedInterface.java \
{public synchronized interface SynchronizedInterface {}} |
compile 命令使用任意数量的命令行自变量，并将它们传递给 Java 编译器。它将返回 PASS、FAIL 或 WARN 来表明编译器的退出状态。
EXPECTED_RESULT 是希望从 compile 命令获得的结果。
在该接口示例中，编译应该不成功。因此完整的回归测试应该类似于：
| tcltest::test 9.1.1-1 {should generate error on synchronized interface} {
saveas SynchronizedInterface.java \ {synchronized interface SynchronizedInterface {}} compile SynchronizedInterface.java } FAIL |
检验结果
运行测试并检查结果是完全自动的，因此可以真正地休息一下，看看出现的结果。Jacks 框架在测试目录中递归下降，运行它所找到的所有测试。
如果一切正常，就不打印任何消息。如果测试失败，将打印有关失败的描述，如 Mo Dejong 在 清单 1 中显示的那样。该例演示了 Javac 中因为第一个构造器调用第二个构造器，第二个又调用第一个所造成的错误。JLS 规定这是非法的（第 8.8.5.1 节），因此如果检测到这种情况，Java 编译器必须用信号通知该错误。
让我们看看 Jikes 对于同一测试案例是如何做的。在 清单 2 中，我们将使用 Jacks 中的一些特性，可以让您将模式作为 Jacks 脚本的第三个自变量传递。将跳过那些名称与模式不匹配的测试案例。在这个小案例中，模式就是测试案例的名称。在该例中，请注意我们所感兴趣的那个测试案例是如何通过的，其它测试案例是如何跳过的。上面的输出表明在 Javac 编译器中找到的错误在 Jikes 中并不存在。
尽管人类可读的结果非常有用，但在您有许多要处理的测试案例的情况下，它们很快就会变得非常难于管理。Jacks 最近庆祝了一个重要的里程碑：现在它包含了逾 1,000 个 JLS 独立测试案例。有了这么多的测试案例，没人能够记住在某一时刻哪些案例通过了，哪些又失败了。但不用害怕，Jacks 包括了一系列记录和测试结果分析特性，能够随时间跟踪测试结果。这是一项关键特性，因为它为 Java 编译器开发者提供了一种跟踪错误修正状态和可能回归的方法。
如何编写 Jacks，以及为什么使用 Tcl
当实现例如 Jacks 这样的测试套件时，脚本语言是个很自然的选择，而使用 Tcl 也有以下几个原因：
Tcl 是开放源码，因此在今后的一段时间内仍然会继续存在。
易于安装，不需要编译脚本。
易于读写，脚本语言远比 C/C++ 更易于掌握。
易于使用字符串处理和常规规则表达式特性。
高度可移植，在比 Java 多的平台上运行。
过去十年中成功地在几千个组织中使用过
具有讽刺意味的是，它曾是 Sun 项目 :)
Mo DeJong 说，“Jacks 最了不起的一个特性是自生成文档。” 在 Jacks 主页上，您可以找到到达测试案例索引页面的链接，这些页面列出了所有可用的测试案例。它以几种有用的方式进行索引和交叉引用。可以方便地通过名称查找测试案例，也可以通过现有测试来发现某个 JLS 章节的内容是多么完善。Tcl 高度动态的语言特性使自记录测试案例的实现更容易。
到目前为止，Jacks 支持以下几种 Java 编译器：
JDK 1.3（1.1 和 1.2 也可以使用，但已经过时了）
Jikes，IBM 的开放源码 Java 编译器
Kaffe，利用了 Kopi 编译器
GCJ，到 gcc 的 Java 前端
随处改进 Java 编译器
Jacks 最初着重只为 Jikes 项目提供编译器测试。原来的目标是要替换为 Jikes 创建的自制测试系统，但这个初衷由于太难建立和使用而被放弃了。人们很快发现，如果测试套件变得更常规一些，就可以为其它 Java 编译器项目使用。这样将会导致已提交测试案例在数量上的增加。至少，让其它 Java 专家评估一下正确性测试案例也并无大碍。
Jikes 项目自然大大利用鉴了 Jacks，但 GCJ 和 Kopi 编译器项目又如何呢？Tom Tromey，Red Hat 的常任 Java 领导者，已经意识到了 Jacks 开发对于 GCJ 项目的作用。“Jacks 对于 GCJ 项目已经有了实际意义。每当我在进行前端编译器更改时就会运行 Jacks，并定期使用 Jacks 查找 GCJ 中的错误。我发现添加测试是桩小事。框架非常易于使用，考虑也很周到。”
在第一次运行了 Jacks 后，Kopi 编译器的项目经理 Thomas Graf 也成了一个拥戴者。“第一次运行产生了 169 个失败的测试。在基于对某些失败测试的分析而应用一些修正后，失败的测试数为 147 个。这些结果非常振奋人心（对于 Jacks:）。结论是：Jacks 测试套件对于提高编译器的质量来说确实是一种非常有价值的工具！”
