【问题标题】:Legacy Java code use of com.sun.net.ssl.internal.ssl.Provider()com.sun.net.ssl.internal.ssl.Provider() 的旧版 Java 代码使用
【发布时间】:2012-10-31 14:58:10
【问题描述】:

我正在使用 2003 年的一些代码。有对以下类的引用:

new com.sun.net.ssl.internal.ssl.Provider()

导致错误:

Access restriction: The type Provider is not accessible due to restriction on required library /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/jsse.jar

有人对使用此类的合适替代方案有任何建议吗?

【问题讨论】:

  • 我不知道那门课,但我能读懂'ssl'。如果那是安全套接字层,请考虑javax.net.ssl.*
  • 很少有任何理由像这样手动实例化提供程序。周围的代码是什么?

标签: java ssl provider legacy


【解决方案1】:

扔掉那行代码。还要丢弃对 com.sun.net.ssl 包及其子包的任何引用:修复导入,以便它们引用 javax.net.ssl. 中的类

这是 JDK 1.4 之前的代码,从 JSSE 单独下载的日子开始。

【讨论】:

    【解决方案2】:

    大多数时候,您实际上并不需要自己创建或获取提供程序实例。正如Oracle Providers documentation 所说:

    通用应用程序不应请求加密服务 来自特定提供商。那就是:

    getInstance("...", "SunJCE");  // not recommended
        vs.
    getInstance("...");            // recommended
    

    此外,只要有提供程序的重载参数,它往往会采用字符串或实例,但字符串(名称)可能更常见。 (传递实例有时会很有用,例如对于某些 PKCS#11 配置,但它不常见。)

    JCA documentation about Providers 应该很有用。

    如果你真的想获得一个特定的实例,你可以使用Security.getProvider(name)。您可以在提供程序文档中找到相应的名称。

    【讨论】:

      【解决方案3】:

      您可以在 Eclipse 首选项Java->Compiler->Errors/Warnings->Deprecated and restricted API 中将此设置为警告或非事件。请注意,正如其他人所说,这不是最佳做法,当您有其他选择时应避免这样做。

      【讨论】:

      • 是的,你可以,但你通常不应该,至少不应该在全球范围内。
      • 为什么要投反对票?这是处理遗留代码的可行方法
      • 作为一般建议,我觉得它很危险。作为一个临时解决方案,它可以是好的。我喜欢您的编辑并删除了反对票。
      猜你喜欢
      • 2020-02-21
      • 1970-01-01
      • 1970-01-01
      • 2021-08-01
      • 2019-07-17
      • 2012-07-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多