Why an outer Java class can’t be static

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

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

What does static keyword do

Every Java programmer knows that if we need to define some behaviour (method) or state (field) which will be common to all objects we define it as static. Because static content (behaviour or state) does not belong to any particular instance or object, it will 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 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 for the below statement, two objects will get created

Employee emp =  new Employee();

One is ‘emp’ (the new Employee();) itself and another one is the ‘class level object’ of Employee class which will get created while JVM will load Employee class into memory and we can refer it by Employee.class. And this class level object holds all the static content of the Employee class either it is a variable or method. If we are accessing any static content through emp object it automatically points to Employee.class object 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 because all emp objects are pointing same copy of that variable from Employee.class object, for more information read Why Java is 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 which
  1. Should be common to all objects of the class.
  2. Should belong to the class and accessible by class name.
  3. Should not need an object of the 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, defining an outer class as static will serve purposes which 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 class while an outer class is part of the package and 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 which is 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 (exception will always be there e.g. java.lang.Math), again there is no need to define an outer class as static.
From the above points, we can say Java 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.

You can find the complete source code for this article on this Github Repository and please feel free to provide your valuable feedback.
Next Post Newer Post Previous Post Older Post Home

8 comments :

  1. Employee emp = new Employee();

    How this sentence will create 2 object? Could you please elaborate?

    ReplyDelete
    Replies
    1. Dear Aki,

      Thanks for your reply

      Whenever JVM finds a class in its execution path it checks whether it is loaded into memory or not, If it is not then JVM loads that class into memory and create a class level object of that class (which is actually an object of java.lang.Class). And JVM does it for first entry of class, for second entry that class level object will already be there.

      Similar in our case Employee emp = new Employee(); JVM will create two objects one is the class level object other is 'emp' itself, the new Employee()

      Delete
  2. A good reason to allow static outer class is to prevent object construction. Instead we have to use the trick of defining a private constructor.

    ReplyDelete
    Replies
    1. Neil, actually we can create objects from static classes. Think of static inner classes, we can create objects from static inner classes.

      Declaring a member static will tell JVM that we are going to access it by using class name and this member does not belongs to any particular objects (instead it will belong to class level object).

      Delete
    2. I understood that your argument was that allowing to define a class as static is unnecesary because it doesn't add any value.
      I was arguing that there is added value in defining a class to only have static methods and no constructor.

      Delete
    3. Okay I get it, but still Java creator have not designed it in a way, so creating a static class will restrict us from having constructor in it.

      But in Java 8 we can create static methods (as well default methods) in an interface, So it will serve the same purpose

      Delete
  3. A good reason to allow static outer class is to prevent object construction. Instead we have to use the trick of defining a private constructor.

    ReplyDelete