Reputation: 101
I am working with some code from back in 2003. There is a reference to the following class:
new com.sun.net.ssl.internal.ssl.Provider()
It is causing an error:
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
Does anyone have any suggestions for a suitable alternative to using this class?
Upvotes: 10
Views: 36751
Reputation: 10955
I used import com.sun.security.sasl.Provider;
in OPEN JDK 21 and works.
Upvotes: -1
Reputation: 3775
You can turn this into a warning or non-event in Eclipse preferences Java->Compiler->Errors/Warnings->Deprecated and restricted API
. Note, as others have said, this not the best practice and should be avoided when you have alternatives.
Upvotes: 1
Reputation: 310893
Throw that line of code away. Also throw away any reference to the com.sun.net.ssl
package and its sub-packages: fix the imports so they refer to the classes in javax.net.ssl.
This is pre-JDK 1.4 code, from the days when JSSE was a separate download.
Upvotes: 10
Reputation: 122649
Most of the time, you don't actually need to create or get hold of a provider instance yourself. As the Oracle Providers documentation says:
General purpose applications SHOULD NOT request cryptographic services from specific providers. That is:
getInstance("...", "SunJCE"); // not recommended vs. getInstance("..."); // recommended
In addition, wherever there's an overloaded parameter for the provider, it tends to take either a string or an instance, but the string (name) would probably be more common. (Passing an instance can be useful sometimes, e.g. for some PKCS#11 configurations, but it's unusual.)
The JCA documentation about Providers should be useful.
If you really want to get hold of a specific instance, you can use Security.getProvider(name)
. You'll find the appropriate names in the providers documentation.
Upvotes: 8