由一次异常引发的思考:为什么在自己编写的Java代码中包名不能以"java."开头?

96
EakonZhao
2017.07.26 12:42* 字数 661
java.lang.SecurityException

今天在阅读Spring源码的时候用junit跑了个单元测试,然后发现报了上面这个异常。很明显,编译器提示现在的包名是被禁止使用的。后来我把包名前面的"java."删除后就能正常运行了。为什么package name不能以"java."开头呢?我打算在等外卖的这段时间探究一下这个问题。

ps:在进一步探究这个问题之前,我首先要向大家安利一下饿了么最近上线的超级会员----饿了么的超级会员每个月只要8块钱,能领4个金额5元的零门槛红包,并且每下满5单之后还能领取1个5元红包,真的超级优惠啊!(饿了么的公关看到之后请支付广告费hhhhh)

饿了么超级会员
饿了么超级会员

好了,言归正传,下面开始进入ClassLoader源码。
我们所编写的Java类通常是交由应用类加载器(Application ClassLoader,也通常被称为系统类加载器)来进行加载的。系统类加载器是通过直接调用loadClass(name)方法来加载一个类的。在破坏双亲委派模型中,拓展一个类加载器通常是继承它然后把自己的类加载逻辑写到findClass()方法中,然后调用defineClass()之后返回。所以我们直接查看源码:

loadClass(String name)源码
protected的loadClass方法
findClass

我们在上面看到loadClass方法调用了findClass方法,而findClass方法的返回又是通过defineClass方法完成的,所以我们直接查看difineClass方法的源码:

defineClass
defineClass

到了这里其实我有点纳闷,因为一点也没看出哪里对包名进行了限制。别急,我们一起来看一下在defineClass函数中第一行调用的函数:

调用preDefineClass函数
preDefineClass函数源码

很明显,从上面的函数源码中我们可以看出在这里对以"java."开头的用户自定义包名进行了限制,
那么类加载器为什么要这么做呢?我猜测原因是这样的:由于JDK中的包名都是以"java."开头的,假如在用户编写的代码中也允许使用以"java."开头的包名,那么在虚拟机类加载的“类或接口解析”的过程中可能发生冲突----比如说我们自己编写了一个Integer类,并且把它放在自己创建的java.lang包中,那么它就会和jdk中java.lang.Integer发生冲突了。

Java知识
Web note ad 1