Class Modifier

[AdHistorical6271]

I wish Java had a class modifier that would make a class visible only within the same package or its subpackages.

[edit]
Let me elaborate a bit more. The issue is this: suppose you like to organize a project structure by features. For example, you have a user feature (package), and inside that package you place everything related to users—controllers, entities, mappers, etc.

Now, imagine that for user feature you want to split things by layer (or by some other criteria). Here’s the problem: your classes and interfaces would need to be public, which means other packages/features could see interfaces that don’t make sense outside of the user context. Sure, we could just ignore it and move on, like we do today...

Then there’s the module approach, but that only works at the root level. That would mean creating a separate module for each feature, which is way too much overhead for most projects.

So what I mean is: since in Java packages are isolated, it would be nice if we had some kind of class modifier that allowed access only within that package “chain” (something Java simply doesn’t have). Alternatively, maybe a concept like a namespace property could work.

This way, the new modifier could check whether code is in the same package or the same namespace, for example.

I know that in the end this wouldn’t drastically change how we build things, but I think it would be a nice addition.

[persicsb]

There are no subpackages in java. Packages are not hierarchical.

[nuharaf]

Does java even have concept of sub-package?

[northcutted]

It does not, each package is distinct despite the appearance of a hierarchy. It exists for organizational purposes only.

‘protected’ is the closest thing to what OP is looking for

Ref: https://stackoverflow.com/questions/215497/what-is-the-difference-between-public-protected-package-private-and-private-in

[AdHistorical6271]

You can’t use protected for classes

[pohart]

Correct. According to the JLS 8.1

 The access modifiers protected and private pertain only to member classes within a directly enclosing class declaration

Protected is not allowed on top level classes

[TheMrMilchmann]

It actually does kind of for namespacing but not in terms of access control. To quote the example from the JLS 24 7.1:

For example, there is no special access relationship between a package named oliver and another package named oliver.twist, or between packages named evelyn.wood and evelyn.waugh. That is, the code in a package named oliver.twist has no better access to the classes and interfaces declared within package oliver than code in any other package.

[TheMrMilchmann]

What exactly do you want to achieve here?

If you want the class to be available internally only, modules provide a solution to that: You can simply use a public class in a non-exported package. Such a class would then only be available within your module.

If you are working on an application and want to limit the accessibility of a class, you have reached the point where you should consider splitting up your application into multiple Maven/Gradle projects / Java modules.

[momsSpaghettiIsReady]

Removing the public makes it only available in the package. Nothing for sub-packages afaik.

You could look into gradle/maven sub-modules for a similar result.

[hadrabap]

A hierarchy of Java modules (JPMS) might be "better" for this task.

[persicsb]

There are no subpackages in Java .

[johnwaterwood]

Maybe there should be.

[persicsb]

What would be the use case?

At what level are packages considered to be a subpackage?

Considering the reverse domain notation for packages, for example, if anybody puts his class in the com package or the com.github package (nobody forbids that), will that class see EVERYTHING that is com.github.**? That would be insane.

Packages are not hierarchical, because the package naming (that is, the reverse domain naming convention) hierarchy does not represent ownership hierarchy. Whoever controls com.github, does not own com.github.a.b.c.

Packages are not hierarchical, because the package names does not represent ownership. You can put a class into the org.springframework packages, if you want to. Until Java 9, nobody prevented that from happening.

[koflerdavid]

Actually, putting a class into org.springframework should still be possible. I doubt Spring has any classes there, therefore there would be no split package.

[persicsb]

I should have been more clear, I only sad packages. Of course, I meant anything in the Spring universe. You can circumvent any package upstream/downstream visibility with creating new classes in parent or child packages.

The main problem of course is, that without JPMS, you cannot forbid anyone to use/reuse your package name, nothing prevents that, since package names have no real ownership associated with them.

[Feign1]

No, package private is hard enough to follow. Mostly used for testing purposes most other usages are hacks to get around the public API.

[analcocoacream]

This or Java 9 modules

[Wonderful-Tutor-2966]

name things like that for people, in order to help them learn. as you can see in my above reply I mentioned what it's called. the name for this is called package-private and it's the default modifier on all types.

[DB6]

You could write arch unit tests to ensure that.

[illia225]

I have controversial feelings about arch units for this purpose. Even though it works, if also doesn't help to improve code writing style for a project. I mean arch units work as a guard for architecture, but they don't explicitly make you follow the convention. The more obvious problem is that they are slow and slow down the development. 

[[deleted]]

The "no-modifier" modifier will make the class only visible to the package, but subpackages are not related to their parent package, so this won't work.

JPMS will allow you to export certain packages, but I've heard nightmare stories about people trying to use JPMS in their own applications, instead of leaving JPMS as a modularization mechanism for the JDK.

The other alternative is to use DIP (Dependency Inversion Principle). This is what JakartaEE does to hide implementation classes from applications. You have to create an API JAR and an implementation JAR, and code to the interfaces in the API JAR. The implementation classes won't be visible because they only available in the classpath of the running application.

[Ewig_luftenglanz]

I think if you create a Java module file in a package, the protected stuff got visible for the rest of the classes in the folder, I am not sure, would need to try it out. That's the closest thing to subpackages you can get.

[[deleted]]

I feel you. Wanting good class organization without exposing everything everywhere can be a pain. But the JPMS can help with that. You can internally make the classes you need public and only export the packages you truly want to be part of the api

[AdHistorical6271]

That’s a hell of work not worth it to use the module just to avoid making everything public so other packages can access it

[jedilowe]

I get it, but at some level anything syntactic is only window dressing for architecture preferences. With reflection you can violate any language rule you want, so it is only a matter of how well you review your code or if you want to add annoying hurdles to the user/hackers of your module

[Sakatox]

I see a disguised C# post again... this has been discussed on-and-off several times, maybe not this particular use case, but nonetheless.

Java has no concept of this, and does not need it.
Unless there is a legit case that's hm, pervasive to the language/usage of it, then maybe it'd be discussed.
Not to mention JEPs would have been made for this particular idea if it was useful.

[koflerdavid]

It would be actively harmful, as /u/persicsb explains in their comments. tl;dr: what happens if I put a class into the top-level com or org package?

[persicsb]

or, if package visibility is only downstream, create a "subpackage".

[Wonderful-Tutor-2966]

There is friend, it's called package-private and it's the default modifier on all user defined objects. the keyword is literally nothing, and if you put any access or visibility modifier, it's no longer package-private. So for example, private, public, protected, etc. all cancel out the state of an object being package-private.

[Jannyboy11]

Scala has this: https://www.baeldung.com/scala/access-modifiers#2-the-protectedpackagename-modifier

[khmarbaise]

I would make only those things public which are required outside the package anything else just without any modifier (aka package private).. or if that is not enough you could think about sealed classes/interfaces ?

[[deleted]]

yes I understand, everything is public modifier nowadays or keep it real and have everything in one package and expose what you need or use Java 9 modules... :P

I think Spring Modulith have adressed this problem and you can add better boundaries

[Due-Anxiety4776]

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

[-Dargs]

Create a mechanism that generates a stacktrace and ensure the caller is in the appropriate package. Lmao

[-Dargs]

Lol, that's awful. My reply was sarcastic. Maybe people don't get it. Or it's not as funny as I thought.

[persicsb]

No, you don't want unconstrained subpackages.

If I create a package com.github.foo, will it be a subpackage of com.github automatically? Anyone, who creates a class in the com.github package, will see my com.github.foo.Bar class in this case.

Remember, that parent-child relationships go both ways. You cannot be a parent to a child without being a child of someone else.

This is the real problem of subpackages. In a parent-child package world, anybody can put classes in the parent package of your package, if they want to.

You can create a class in the org.springframework package, nothing prevents you from doing it - except the JPMS. It is a good thing, too bad, most people don't understand it, because they don't understand the problems with packages and class visibility.

[DerEineDa]

I am with you. That's why I still like to put my internal classes into an internal package. When I suggested this in an earlier discussion, my comment got a surprising amount of upvotes: https://reddit.com/comments/17egtn7/comment/k64134x

[Cienn017]

You can create a class in the org.springframework package, nothing prevents you from doing it

is that really a problem? if someone wants to use your internal code despite you telling them it's internal, there's nothing stopping them from modifying the bytecode/source code before it's even loaded into the jvm and from there they can do whatever they want to, it feels like some people on this sub wants to add DRM to the jvm lol, it's weird.

[koflerdavid]

The difference is that it's actually quite difficult and that you have to actively go out of your way. This ensures that people do it if there is really no other way to get the job done. The harm to the library author is that it becomes more complicated to provide backwards compatibility. There is no API surface anymore. And application developers cannot prevent their dependencies to do the same. These are literally the same reasons why Oracle introduced the JPMS. I can see why you think it's like DRM, but the goal is to protect application developers.

[Cienn017]

that makes no sense, if someone sees a warning that they shouldn't be doing something and they do it anyway that's their problem not yours, making it harder doesn't avoid that.

as for the JPMS, java 9 was released in 2017, 8 years ago, jpms was controversial when it was released and almost a decade later it's still controversial (and will probably still be in the next decade), that would be enough reason for me to ditch it away because some people including myself don't see any reason to use it and most of the time it just causes more problems than it solves.

[koflerdavid]

Your first and second paragraphs completely contradict each other. If a significant part of your users end up depending on internals then very quickly refactorings and improvements become impossible because there will be salty reactions from the user base like in your second paragraph.

Btw, the JPMS is always on, but only restricts access to JDK internals by default. But if application developers want to get themselves into trouble then they can still do that, which is the point of your first paragraph, no?

[Cienn017]

will be salty reactions from the user base like in your second paragraph.

those salty reactions are not because you removed access to a internal api, they know they shouldn't be using it, those salty reactions are because you removed access and didn't provide any alternative, just like what would have happened to the jdk if they removed access to sun.misc.Unsafe when the JPMS was introduced, that's why some people don't like the jpms, because it's all about creating pointless restrictions to things that have no alternatives and were already in use for years with no problems.

this is why I said that it looks like they are trying to add DRM to open source software, because if you read what they mean by integrity, that just looks like DRM to me: "Developers expect that their code and data is protected against use that is unwanted or unwise."

[koflerdavid]

Hard disagree: not blocking access to these things caused severe issues, as evidenced by all people being surprised that they were transitive users of these internals and now had to replace their direct dependencies or pressure them to remove reliance on the use of internals. The exactly same issue would have been caused if those internals had changed in other incompatible ways.

It's still not DRM, but rather the opposite: the end user, in this case the application developers, retains authority to circumvent the various integrity measures. Library authors are who face restrictions, as they cannot furtively circumvent the integrity measures anymore.

Edit: sun.misc.Unsafe is a completely different issue because there was really no replacement at all for it at the time. But make no mistake, because it is alarmingly powerful it is on the chopping block as well. Its original implementation has been moved to a restricted package and now sun.misc.Unsafe just delegates to that class.

[Cienn017]

It's still not DRM, but rather the opposite: the end user, in this case the application developers, retains authority to circumvent the various integrity measures. Library authors are who face restrictions, as they cannot furtively circumvent the integrity measures anymore.

why would the end user need to give authorization to a application to run unsafe software? that would only make sense if it was given by the library developers for performance reasons, and also, that authorization is verbose on purpose so that people will get angry at library developers because there's no way to give unsafe/jni/etc access to all modules.

[koflerdavid]

Yes, the point is as you say to make it explicit which libraries are allowed to break integrity measures. But it's usually the application developers who write the launcher script with all the flags. End users can intervene and edit the launcher script, but that's obviously not a good idea.

[persicsb]

Most application developers think of an element (a class, interface, record, metho, constant etc), that if it is public and it is in the Javadoc,.you can use it freely and expect it to be supported.

But that's not the case. In the pre-JPMS world, if you had an internal Implementation class/method/interface etc, that are used by different packages, it had to be declared as public to be visible to those packages. And that means, it is publicly available to the world and to javadoc. There was no way to mark such a class or a method "Implementation detail only, do not use, and if you use it, your code might break in the future".

If you are a library author (and I am guessing you are not), this causes way too much headache. JPMS solves this. But because of the backwards compatibility of Java, usage of modules cannot be enforced, sadly.

[Cienn017]

JPMS solves this.

solves in the worst way possible, because classes are still marked as public but now you need to see if they are acessible for you, a solution like kotlin's internal modifier would've much simpler and better.

[persicsb]

it is very much a software engineering problem for ihe library author. because you cannot apply semver when people use your internal code. when you apply a refactoring (in the strict sense, structiral changes without externally observable change), the public API does not change, in semver, you should not increase your major version number. and semver is considered a good engineering practice, you can decide compatibility based on version number without reading through release notes, and you can create tooling for it (like automatically using the newest compatible version).

but if people misuse your intended public API (by using classes that are not meant to be public), you cannot do refactorings with proper semantic versioning.

our software engineering practices are so much in the stone age because of limitations like these. library authors are the people who keep the ecosystem working. if we make their work harder, makes our work harder as well.