为何Java子包无法访问父包的默认类与默认方法？

两个报错的直接原因 #

代码里的两处报错本质都是触发了Java默认访问权限的拦截规则：

• 第一处：AA类虽然用public修饰，允许跨包访问类本身，但它的a()方法没有声明任何访问修饰符，属于默认访问权限（也叫包私有权限），仅和AA同属a包的类可以调用该方法，处在a.b包下的B自然没有调用权限。
• 第二处：类A本身没有声明访问修饰符，同样是包私有权限，仅a包内的类可以访问、实例化该类，跨包的B无法直接实例化A。

默认访问权限的设计逻辑 #

Java的访问控制体系核心是为了定义清晰的封装边界，默认的包私有权限定位非常明确：给同包内紧密协作的互信类开放调用权限，对包外所有代码隐藏实现细节。

• 包在Java的设计逻辑里，是一组功能高度内聚、由同一组维护者迭代、彼此信任的类的集合。对于不需要对包外暴露的工具类、内部实现方法，用默认权限修饰，就可以避免外部代码依赖这些不稳定的内部逻辑，后续重构内部实现时不会影响包外的业务逻辑，是比private范围稍大、专门服务于包内协作的封装层级。
• 这个权限的判定规则是严格的包名完全匹配，不存在任何基于包名层级的权限继承逻辑。

子包不属于父包权限范围的核心原因 #

很多初学者会把文件系统的目录层级逻辑套用到Java包规则上，误以为a.b作为a的子包天然拥有父包的访问权限，实际上Java从设计之初就刻意否定了这种规则，核心原因有两个：

• 第一是避免封装边界失效。如果子包自动拥有父包的包私有访问权限，意味着任何人都可以通过定义一个a.任意名称的包，直接访问a包下所有包私有成员，包私有的封装作用会完全消失，根本起不到隐藏内部实现的作用。
• 第二是契合包的职责划分逻辑。包名的点分隔仅作为命名空间的层级标识，用来避免类名冲突、做功能的逻辑归类，不代表代码的内聚关系。实际开发中子包往往是父包功能的拆分、扩展或者特定场景实现，和父包的维护者、变更节奏、信任边界都可能不同，天然不应该默认拥有访问对方内部实现的权限。

补充：如果确实有跨包访问的需求，要么把需要互访的类放到同一个包下（这也是最符合包私有设计初衷的做法），要么把对应成员声明为protected（仅允许子类访问），不要试图通过定义子包的方式绕过权限校验。

内容的提问来源于stack exchange，提问作者xiaotan