Java安全机制实现的不合理性

当谈到java安全机制的原理时，自然想到类SecurityManager。
当判断某个方法是非有权限执行时，都是采用如下方式：在该方法的开始地方check是非有权限。
例如，判定calling Thread 是非可以加载某类库时，
代码如下（取自loadLibrary0(Class fromClass, String libname)方法）：

SecurityManager security = System.getSecurityManager();
        if (security != null) {
            security.checkLink(libname);
        }

像大致这样的代码遍布的java源码的各个角落，这样觉得太不好了.
比如上面代码，如果以后需要改变loadLibrary0方法的权限，怎么办呢？
你或许会说，修改SecurityManager中的checkLink不就行了吗？ 这个肯定不行的，SecurityManager是个公共类，修改它或许会影响到其他地方。
你或许会想，在SecurityManager中新增一个方法，取名为checkLinkToLib,然后再修改上面提到的loadLibrary0方法。
这样做可以保证不影响其他，但是一个小小的需求却改动了两个地方，好像不是我们所情愿的。
＝＝＝＝＝＝＝＝＝＝＝＝分割线＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我能想到的：对于现在安全机制的解决办法，是面向切面编程，这样灵活性就更大了。

权限这个东西就这么繁琐，不止是java的问题，它本身就是那样。
对应用来讲，是可以做到一定程度功能和权限分离的。
对底层服务来讲，检查权限通常就是程序的一部分。

JVM比loadLibrary还要底层些。

这个是基础类库不是应用系统，不需要那么灵活。按照软件设计的理论，越是底层的，被依赖的越趋近于稳定。
这还不包括在性能，稳定性，可维护性等的权衡。
当然楼主说的也有道理

不是可以使用策略文件么？
grant codeBase "file:....." {
permission java.io.FilePermission "a.txt" "read"
}

+

面向切面的话,要使用动态代理来实现吧,这样性能好像有影响

楼上说的对，顶起！

SecurityManager 提高一套模板实现，通过配置policy文件来控制。

底层的安全与应用级别的安全是两码事！

确实，应用级别安全需求千差万别，底层安全只是追求稳定可靠通用