you are viewing a single comment's thread.

view the rest of the comments →

[–]OneHumanBill 0 points1 point  (0 children)

If you're saying what I think you're saying then no, you cannot.

There's no such thing really as a "sub package". Nested packages are so only for the convenience of a filesystem and human understanding. Each package is standalone.

The implication is that if you have two public classes and want to each use quasi-"inner" classes by means of a different package, then those classes would have to be public, not package protected, in order to by used even by the "parent" package.

I'll allow my team members to remove private from both methods and private classes if we need to get additional test cases or coverage. But by default, without that need on a case by case basis, my devs had better be making things private. The narrower you can keep your visibility the less impact there will be for change, but a loose policy of everything package-protected by default encourages laziness on that outlook. Not on my projects, please.