I found this article very interesting, as I use plugins very frequently. As Ulf has used some deprecated methods in the SecurityManager, I had a look to see how it could work without using deprecated methods.
My aims are slightly different to Ulf's. I started with an interface called ThirdPartyPlugin and wanted to put tight security round any class that implements this plugin, whether loaded from the classpath or via a custom loader. This prevents anyone slipping a rogue plugin onto the classpath. I also want to allow the plugin to instantiate any existing or new classes from any package - so the developer can spread his or her code across several new classes.
It turned out that I did not need a custom classloader, but it's still nice to use one to keep third-party code separate. However, my SecurityManager code is a bit clumsy without using the deprecated methods. Basically the SecurityManager has to navigate up the callstack and find out if any classes implement the ThirdPartyPlugin interface. If so, that's when it needs to throw SecurityExceptions.
One further quirk - when the third-party plugin needs to instantiate a class that is not in the standard
Java packages, SecurityManager.checkRead(
String file) gets called, so here the SecurityManager needs to allow the call to succeed if a ClassLoader is in the callstack before the ThirdPartyPlugin.
If there's a more elegent solution, I'd be interested to know about it.
Here's my SecurityManager code...