刚刚展示的这个例子，在扩展目录下JAR导致的众多问题来说不算很复杂。例子中，至少有一个NoSuchMethodError来提醒这个问 题。一个潜在的更加复杂的情况是，旧的类有和新类一样的方法签名但实现的方式已经过时。在这种情况下，可能没有错误、异常或者throwable中任何一种，但是应用的逻辑不会像预期那样工作。旧的方法可能会一直存在代码的底层直到被发现。当缺乏单元测试或其他测试时尤其如此。
　　使用扩展目录会让开发人员变得轻松。因为扩展目录下JAR文件中的类，可以被所有运行在与此扩展目录（如果在操作系统上在主机范围内启用扩展目录，那么所有主机上的JRE都可以访问）关联JRE上的应用访问。然而，随意使用扩展目录会有一定的风险。你会非常容易忘记扩展目录下过时的类。这会妨碍类加载器选择明显应当被加载的版本。这种情况下，本来应该让开发者感觉轻松的扩展机制会让他们非常痛苦。
　　Elliotte Rusty Harold提对扩展机制有一个警告：“尽管这些看上去很方便，从长远来看也是引入了一个隐患，迟早你会从一个你根本没想过的地方载入一个错误的类版本。这会浪费你不少时间调试”。Java教程同样提出警告（我在这里也着重强调）：“尽管这个机制扩展了平台的核心API，但是应该审慎使用。大部分情况，它是用于像JCP这样标准化比较好的接口，同时也适用于整个站点的接口”。
　　尽管扩展（可选包）机制与classpath机制很像，并且它们都用于部分的类加载，两者之间的区别也是非常值得注意的。特别的，记住所有的在扩展目录下的JAR文件（即使它们没有以.jar结尾）都会被加载是很重要的。给那些JARs重命名甚至改变他们的文件后缀名都不足以让类加载器忽略它们。另一方面，使用classpath的时候，重命名classpath中指定的JAR文件会使该JAR无法加载，改变后缀名后，即使在classpath中使用通配符也无法加载所有目录中的JAR。
　　一些情况下，扩展机制是比较好的选择，但是这种情况相当少。当处理预期以外的NoSuchMethodErrors问题时，记住扩展机制使很重要的。这样会去检查看看是否问题出在扩展的目录中。