java8 : dealing with default methods

Question

在编写加密实用程序类时，我遇到了以下方法的问题:

public static void destroy(Key key) throws DestroyFailedException {
    if(Destroyable.class.isInstance(key)) {
        ((Destroyable)key).destroy();
    }
}

@Test
public void destroySecretKeySpec() {
    byte[] rawKey = new byte[32];
    new SecureRandom().nextBytes(rawKey);
    try {
        destroy(new SecretKeySpec(rawKey , "AES"));
    } catch(DestroyFailedException e) {
        Assert.fail();
    }
}

在 javax.crypto.spec.SecretKeySpec 的特殊情况下，上述方法在 java7 中工作得很好，因为 SecretKeySpec (javadocs 7)没有实现 Destroyable (javadocs 7)

现在使用 java8 类 SecretKeySpec (javadocs 8)已制作Destroyable (javadocs 8)和方法Destroyable#destroy现在是 default 这很好根据 statement

Default methods enable you to add new functionality to the interfaces of your libraries and ensure binary compatibility with code written for older versions of those interfaces.

尽管类 ScretKeySpec 本身没有改变，但代码编译没有任何问题，只有接口(interface) SecretKey已经。

问题是在oracle的jdk8中destroy方法有如下实现:

public default void destroy() throws DestroyFailedException {
    throw new DestroyFailedException();
}

这会导致运行时出现异常。

所以二进制兼容性可能没有被破坏，但是现有代码已经被破坏了。上面的测试通过了 java7 但没有通过 java8

所以我的问题是:

• 一般如何处理可能导致异常的默认方法 - 因为未实现或不受支持 - 或运行时的意外行为？除了做

  Method method = key.getClass().getMethod("destroy");
  if(! method.isDefault()) {
      ((Destroyable)key).destroy();
  }
  

  仅对 java8 有效，在未来的版本中可能不正确，因为默认方法可能会得到有意义的实现。

• 将此默认方法留空而不是抛出异常不是更好吗(IMO 具有误导性，因为除了合法的销毁调用之外，没有任何东西试图有效地销毁 key ，UnsupportedOperationException 会更合适，你会立即知道发生了什么)

• 我的方法是(类型检查/转换/调用)

  if(Destroyable.class.isInstance(key))
      ((Destroyable)key).destroy();
  

  对于判断是否销毁有误吗？有什么替代方案？

• 这是误解还是他们只是忘记在 ScretKeySpec 中添加有意义的实现？

Answer 1

Is this a misconception or did they just forget to add meaningful implementation in SecretKeySpec?

他们没有忘记。 SecretKeySpec 确实需要一个实现，但它还没有完成。查看错误 JDK-8008795 .抱歉，尚无关于何时修复此问题的预计时间。

理想情况下，destroy 的有效实现应该在添加默认方法时添加，并且接口(interface)被改造到现有类上，但它并没有发生，可能是因为调度。

您引用的教程中的“二进制兼容性”概念是一个相当严格的定义，Java Language Specification, chapter 13 使用的就是这个定义。 .基本上它是关于库类的有效转换，当与针对这些库类的旧版本编译的类结合时，不会在运行时导致类加载或链接错误。这与导致编译时错误的源代码不兼容和行为不兼容形成对比，这通常会导致系统运行时行为发生不需要的更改。比如抛出之前没有抛出的异常。

这并不是要尽量减少您的代码被破坏的事实。这仍然是一个不兼容。 (对不起。)

作为解决方法，您可以添加 instanceof PrivateKey || instanceof SecretKey(因为这些显然是缺少destroy 实现的类)并让测试断言它们确实抛出DestroyFailedException，否则如果instanceof Destroyable 执行测试中的其余逻辑。当这些实例在某些 future 的 Java 版本中得到合理的 destroy 实现时，测试将再次失败；这将是一个信号，将测试改回对所有 Destroyable 调用 destroy。 (另一种方法可能是完全忽略这些类，但这样有效的代码路径可能会在相当长的一段时间内未被发现。)