What Is the Default Access Modifier in Java

What is the default access modifier in Java?

From Java documentation

If a class has no modifier (the default, also known as package-private), it is visible only within its own package (packages are named groups of related classes — you will learn about them in a later lesson.)

At the member level, you can also use the public modifier or no modifier (package-private) just as with top-level classes, and with the same meaning.

Full story you can read here (_{Which I wrote recently}):

http://codeinventions.blogspot.com/2014/09/default-access-modifier-in-java-or-no.html

What is the default access specifier in Java?

The default visibility is known as “package-private” (though you can't use this explicitly), which means the field will be accessible from inside the same package to which the class belongs.

As mdma pointed out, it isn't true for interface members though, for which the default is "public".

See Java's Access Specifiers

Default access modifier for a Java constructor

Constructors are the same as methods in this respect - if you don't give an explicit public, private or protected then the constructor gets the default "package private" visibility. It can be called from within the same class or from any other class in the same package, but not from subclasses in a different package (so if a class has only package-visible constructors then any subclasses must be in the same package).

A private constructor prevents any other class from instantiating this one, but you can have a public static factory method within the class that calls its own private constructor. This is a common pattern for things like singletons.

Protected and default modifier Java

Default access modifier (no keyword) is more restrictive than the protected access modifier, meaning when a method has a protected access modifier it's only visible to classes in the same package and sub-classes.
On the other hand, (no keyword) access modifier is accessible only for classes in the same package.
Another thing that you have to know, is one of the overriding rules is that the overridden method must have the same or less-restrictive access modifier.

Rules of overriding a method:

1. Only inherited methods are overridden
2. Method in child must have the same signature as the method in the parent
3. Final, private and static methods cannot be overridden
4. Must have the same return type or sub-type
5. Access-modifier must be less-restrictive than the one in the parent
6. Must not throw new or broader checked exceptions

java access modifiers : no-modifier vs default

The "default" access modifier is when there is no access modifier given (that is, not one of public, private or protected).

default the keyword is used in the context of a switch statement. It is the "default action" to take if none of the other cases match.

Default access modifier for interface methods in Java 9?

The Java 9 Language Specification says in §9.4::

A method in the body of an interface may be declared public or private (§6.6). If no access modifier is given, the method is implicitly public. It is permitted, but discouraged as a matter of style, to redundantly specify the public modifier for a method declaration in an interface.

Unfortunately, I can't find a link that does not lead to a PDF, diffing the old and new JLS.

Why can't we specify default access modifier for a class

The default access modifier in Java can be used by just omitting any access modifier. Java 8 introduced a new default keyword used to provide a default implementation for an interface's method but, despite its confusing name and location in the method's declaration, it has nothing to do with access modifiers.

Can we changed the access specifier of a method from private to default just for the sake of method level unit testing

'default', i.e., the absence of a modifier, means package private in Java. Only classes in the same package can access it. Sometimes it is desirable to test an internal method meant for private use of that class in a unit test separate from the rest of that class in order to cover all code paths with clear, concise, and simple tests. When you do this (and the result is cleaner test code that can be maintained with more ease) it is fine to mark that method as package private.

This is not an uncommon strategy. Because the only classes who can use this method must reside in the same package, you still have plenty of control over its use.

Personally I would recommend only doing this for static utility methods that do not depend on the state of their parent class. It is also a very useful technique for testing static methods in abstract classes.

Note that in some cases the need to test private methods may point to the need to break out that part of the class into a separate class instead. This discussion shows some of the common standpoints varying from strict OOP adherence to pragmatism. You often have the possibility to break out that method and make it into a proper public static utility, but that doesn't always make sense, and it doesn't necessarily lead to easier maintained code.

---

Related Topics