On Thu, Sep 10, 2015 at 8:10 AM, Alan Bateman <[email protected]> wrote:
> > If I understand you then you are finding these usages with JDK 7 and JDK 8 > because you're forced to configure the security policy to grant access to > these sun.* packages. So some extent then it means you have a head start. > Yes, thats right. We use the "forbidden-apis" tool Uwe mentions to statically scan for these classes, it will fail the build on usage of internal java apis, but it doesn't detect any accesses by reflection and isn't yet easy to apply to all your third party dependencies, too (https://github.com/policeman-tools/forbidden-apis/issues/38). We have used securitymanager in tests for some time now, for a number of reasons (e.g. detect bugs like bad filesystem accesses), and have been trying to minimize the permissions over time. Of course this only works when there is proper test coverage, and only recently (last year) did we become more aggressive and e.g. break out RuntimePermission("*") as we became more conscious of the problems and the benefits of cleaning it up. We also really try to keep dependencies minimal for both software projects. So I guess thats just more explanation of our experience/concerns. Personally I really really like the idea here, but I am a bit worried about projects especially with many dependencies that don't have this tooling etc in place (and ours is far from perfect), and might grossly underestimate the amount of effort needed to get things working. I don't speak of just internal package accesses, but also stuff like this, look at the top voted answer, its not URLClassLoader.newInstance() or anything like that: http://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime We just fixed that one in elasticsearch only this spring/summer and it required revamping the entire plugin mechanism from single to multi-classloader, this was a lot of code to clean up.
