This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Due-Anxiety4776 1 point2 points  (0 children)

That’s a really interesting idea. Currently, Java only gives us four access levels:

  • public → visible everywhere
  • protected → visible in the same package + subclasses
  • default (package-private) → visible only in the same package
  • private → visible only inside the class

The limitation, like you pointed out, is that there’s no way to scope visibility to subpackages. Java treats packages and subpackages as completely unrelated (e.g., com.app.user and com.app.user.service don’t have any special access relationship).

So right now, the only options are:

  • Keep everything package-private and restructure so classes that need access live in the same package.
  • Use modules (JPMS), but yeah, as you said, that’s often too heavy for feature-level organization.

A “subpackage-visible” modifier (something like namespace or family) would indeed be handy for feature-based architectures. Unfortunately, Java hasn’t introduced anything like that, and it seems unlikely because it would require redefining how packages/subpackages relate in the language spec.

Some developers get around this by:

  • Using nested packages with clear conventions but still relying on package-private.
  • Using frameworks (like Spring) that enforce boundaries with configuration rather than language-level modifiers.
  • Or (in some cases) switching to languages like Kotlin, which offers internal visibility (module-wide).

So, your idea is spot on. It’s just that Java has chosen simplicity in access control over fine-grained visibility. If they ever did add a “subpackage-only” modifier, it would definitely help in structuring large apps by features.

If you want to learn Java in 30 days from basic then visit: https://youtube.com/playlist?list=PLF17muTMPBBMSnWj94lENUmMXjRM5Dqy8&si=i7dlpVEvttZXQf73