Java define a explicit package-private modifier [closed]

Question

Obviously Java has a Access level package-private which achieved by not adding any explicit modifier.

But isn't there a way to explicitly add this modifier? It's a bit confusing that we need to omit access level when we want to use member in package only.

If there's no way, why package private decided to be a default level?

For example if default level was public than we would more consciously define relevant access level.

This isn't duplicate of question of why use it, because I know why, I just don't know why it's define implicitly and can't be defined explicitly.

EDIT

You can define it explicitly by using Lombok's @PackagePrivate

Used to indicate the explicit intention for the annotated entity to have the package private access level. Currently used by FieldDefaults and Value to avoid having it make a field one of public, protected, or private.

@PackagePrivate String thanksLombok;

Softspoken

Why? Because that's how they designed the language, wayyy back when. – Margravine

@Margravine Why not providing this very specific case of level got to be the default and can't be defined explicitly? E.g. If default was public than we would more consciously define relevant access level – Softspoken

But isn't there a way to explicitly add this modifier? I guess no explicit modifier means no – Throb

@user7294900 "If default was public than we would more consciously define relevant access level" I don't follow. Why would a default of public do that? You always have to consciously decide on access level, by either writing a keyword, or not. Not writing a keyword is still a conscious decision. – Margravine

Why? I guess because putting stuff inside a folder (package) should mean that I want them to be accessible by default. protected is similar but it will leak access to sub-classes in other packages. I too would have chosen package-private to be the default because of this reason. – Bohner

@Bohner so you are saying it's access based on physical directory and not code? – Softspoken

@user7294900 package-private means accessible to the package, and a package is nothing but a directory in the operating system.. so if access is based on package, it implies access is based on physical directory, yes – Bohner

@Margravine I think not writing something is not always a conscious decision, specially for new comers – Softspoken

Possible duplicate of Java default access level (package private access). Why it is used for? – Caffrey

@user7294900 If you feel that not writing something is not always a conscious decision: Since all code within a package is in an implicit trust relationship, the default of allowing cross-class access within the package makes sense. Granting extra access should be a conscious decision, made after considering all the implications, so a default of public is certainly wrong. – Margravine

@Bohner I think your comment can be an answer if you want – Softspoken

I have a @package_local annotation when I want to make it clear I intended to make a member package local rather than I forgot to define it. – Cirrocumulus

@PeterLawrey It's just a Tag/marker interface? – Softspoken

@PeterLawrey guava has one such too @VisibleForTesting, a little different purpose, but the idea is around that too – Delija

Answer 1

In my opinion,

It would be bad if the default was

public because you could miss specifying the modifier and the piece of code that was intended to be private or something would be accessible to the world. Also, this might be against one of the OOP's core concepts - encapsulation.

private because generally you would want to interact with other classes instead of writing everything in one class.

protected because I would expect (personal opinion) things that are in a folder (package) to be accessible inside the folder and not in a class (child class) residing in some completely different directory.

---

If I were to do it again, I would choose package-private as the default because if some things are together (in the same package), the intention might be that they should be able to talk to each other.

Bohner

Just a comment, in interface no modifier is implicitly public ,which can create confusion – Softspoken

I do not agree with your reasoning for a private default being bad. Defaulting to the most restrictive option generally makes sense. If you ever do try to access it from outside the class you will immediately get a compiler error and see that you need to relax the access. And if you never try to, then private was the correct choice. Whereas if you intended it to be private, but accidentally left it package private, you may never notice that you've left it less restrictive than intended. – Centipede

@SeanBurton Valid point. So the choice is between what you said, and package-private. I would still choose package-private and risk my members being visible to others in the same package. After all if it's in the same package, the code is under my control and there is not a huge benefit in blocking access when I can go ahead and change access any time. Writing the keyword protected all the time even when I am talking to my own code within the same package, might be annoying. Again, we might not agree, but that's ok as the question is marked as opinion-based. – Bohner

Answer 2

But isn't there a way to explicitly add this modifier?

No there isn't. (Short of modifying the Java language, which is highly unlikely for something like this.)

The rest of your question calls for opinion-based answers¹ and is off topic.

---

^{1 - 1) We were not in the room ~25 years ago when the design decisions were made. 2) There is (AFAIK) no extant publicly available documentation for the original language design decisions. 3) The people who were in the room will have probably mostly forgotten, even if we could ask them. 4) Any attempt by your / me to "reverse engineer" the original thinking will be colored by ~25 years of hindsight.}

Equites

See my edit, You can define it explicitly using lombok's @PackagePrivate – Softspoken

Lombok isn't Java. – Equites