Strange user system class loader and MessageDigest behavior

I have an application that uses a custom system class loader specified by the Djava.system.class.loader=class parameter. The application uses RMI. Everything works fine from eclipse, but if I export a runnable jar, this error will occur:

 Caused by: java.lang.SecurityException: SHA MessageDigest not available at sun.rmi.server.Util.computeMethodHash(Unknown Source) at sun.rmi.server.UnicastServerRef$HashToMethod_Maps.computeValue(Unknown Source) at sun.rmi.server.UnicastServerRef$HashToMethod_Maps.computeValue(Unknown Source) at sun.rmi.server.WeakClassHashMap.get(Unknown Source) at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source) at sun.rmi.registry.RegistryImpl.setup(Unknown Source) at sun.rmi.registry.RegistryImpl.<init>(Unknown Source) at java.rmi.registry.LocateRegistry.createRegistry(Unknown Source) 

Naturally, I tried to catch this problem, and wrote a simple MessageDigest md = MessageDigest.getInstance("SHA"); as the first line in my main. Basically the same thing happens. Exact error:

 java.security.NoSuchAlgorithmException: SHA MessageDigest not available at sun.security.jca.GetInstance.getInstance(Unknown Source) at java.security.Security.getImpl(Unknown Source) at java.security.MessageDigest.getInstance(Unknown Source) 

Then I tried using a simple ClassLoader as a SystemClassloader. now it looks like this:

 public class RootClassLoader extends ClassLoader{ @Override public Class<?> loadClass(String name) throws ClassNotFoundException { return super.loadClass(name); } public RootClassLoader(ClassLoader loader){ super(loader); } } 

and the same thing happens anyway. If I rebuild this scenario as a new project, everything will work as expected, so obviously something else is broken, but now I have no idea what.

I do not use a security manager anywhere in the program, and I use standard jre7 with oracle.

Anything I could miss?

Update: Even if I do not redefine the loadClass method at all, an error occurs ... It seems that this happens simply because there is a non-standard system class loader, regardless of what it actually does

Update 2: I have listed all available Securityproviders / algorithms. When I execute the Code in eclipse (still with a custom class loader), everything looks in order, but when executing the executable jar, the full SUN version 1.7 provider seems to be missing. Without a custom classloader, everything is the same. In an environment that only contains szenario above (and that works), everything looks the same, and each constellation has a SUN version 1.7 Provider.

Update 3: -verbose:class showed that the package sun.security.provider and no longer loads. I don’t know why, though, since both alternatives download classes from jsse.jar , where the missing package comes from, and both print [Opened C:\Program Files\Java\jre7\lib\jsse.jar] (Update 4: actually in fact, it loads. Much later. Even sun.security.provider.SHA loads in both variants. This is even more strange)

+4
source share
1 answer

I found the root of this problem. I don’t know why and how it actually happened, but it seems that the third-party library that I used was the culprit. When I removed lib, everything worked fine. Again, I have no idea how this is possible.

0
source

Source: https://habr.com/ru/post/1497994/


All Articles