Why an Outer Class Can’t Be Static

In a previous blog, I talked about why we cannot define an outer class using private or protected keywords. If you have not read it, please go ahead and give it a look.

I this article, I will talk about the use of the static keyword, why an outer Java class can’t be static, and why it is not allowed in Java to define a static outer class. In order to understand that, we first need to understand what the static keyword is used for, what purpose it serves, and how it works.

What Does the Static Keyword Do?

Every Java programmer knows that if we need to define some behavior (method) or state (field) that will be common to all objects, we define it as static. Because static content (behavior or state) does not belong to any particular instance or object, it will be common to all objects and all objects are free to change any static field — and every change will be visible to every object.

We do not need to create an object of the class to access a static field or method. We can directly refer a static field or method by using class name and dot operator e.g. Class.forName(“ClassName”).

This happens because JVM creates a Class-level object for every class when Classloader loads the class into memory. And all static content of that class belongs to this Class object, and all other objects of that class refer to this class-level object for all static content. A class-level object is actually an object of java.lang.Class, and it is referred by your_class_name.class syntax.

For example, in the statement below, two objects will get created:

Employee emp =  new Employee();

One is ‘emp’ itself, and the other one is the ‘class-level object’ of the Employee class, which we can refer to with Employee.class. And this class-level object holds all the static content of Employee. It's either a variable or method. If we are accessing any static content through emp, it automatically points to Employee.class to access that. 

That is the reason why a static variable got changed for every object. Even if we change it for a single emp object, all emp objects are pointing to the same copy of that variable from Employee.class. For more information, read Why Java Is a Purely Object-Oriented Language... Or Why Not?

Why an Outer Java Class Can’t Be Static

From above, we can conclude that we should define members as static that should:

1. Be common to all objects of the class.
2. Belong to the class and accessible by class name.
3. Not need an object of class to access them.

Now, suppose we are defining an outer class as static, and suppose we are allowed to do so. Will this serve any purpose or provide any advantage to a developer, or it will create ambiguity and complications for both developers and language creators?

Let’s check: Will defining an outer class as static serve the purposes that we have defined above or not?

1. Every class is already common to all of its objects, and there is no need to make it static to become available to all of its objects.
2. We need a class name to access its static members because these members are part of a class while an outer class is part of a package. We can directly access the class by just writing package_name.class_name (similar to class_name.static_field_name). So again, there is no need to do something that's already there by default.
3. We do not need any object to access a class if it is visible. We can simply write package_name.class_name to access it. And by definition, a class is a blueprint for its objects, and we create a class to create objects from it (though an exception will always be there, like java.lang.Math). Again, there is no need to define an outer class as static.

From the above points, we can say Java's creators had not allowed an outer class to be static because there is no need to make it static. Allowing to make the outer class static will only increase complications, ambiguity, and duplicity.