Is it a good idea to use static inner classes in Java as POJOs

Question

When we usually want to create a collection consisting of POJOs like List<MyObject> = new ArrayList<>(); we usually create public class MyObject on its own.

But what if we create a private static MyObject inner class in the parent class in which the collection is declared?

Here's an example:

public class MyClass {
    public static void main(String args[]) {

        List<MyObj> objList = new ArrayList<>();

        for (int i = 0; i < 10; i++) {
            MyObj obj = new MyObj();
            obj.name = "Odel B Jr.";
            obj.age = "2";

            objList.add(obj);
        }

        System.out.println(objList);

    }

    private static class MyObj {
        private String name;
        private String age;

        @Override
        public String toString() {
            return "MyObj [name=" + name + ", age=" + age + "]";
        }
    }
}

Notice that this creates 10 new static Objects.

My thing is, which is better? 10 new static objects or 10 new regular java objects?

I'm trying to approach this from JVM's point of view - i.e. with a focus on performance. Not really about design/accessibility of objects according to Java OOP principles.

It depends upon the desired visibility and the underlying modeling for the application. Is the `MyObject` only used with a class (and not serialized)? Then scope limitation is probably fine. But my first inclination would be that something might be amiss with the modeling. Why exactly is there an object only of relevance within the particular class? But only the application and the data model know for certain. — KevinO, Mar 04 '19 at 02:05
@KevinO ok but what's the implication of `MyObject` being a static inner class vs regular class? — AlphaNumerical, Mar 04 '19 at 03:12

mcvkr · Answer 1 · 2019-03-04T02:57:40.517

If the object MyObject will be accessed outside of your class it needs to be public, such as if it is a domain object.

If the objects and methods outside of your class do not need to use MyObject directly it is a better practice to create your class as private and hide the details of its implementation. This aligns very well with the object-oriented programming (OOP) principle Encapsulation, some say it is one of the four basic principles of OOP.

If you wonder what needs not to be shared, think about this scenario; you have a Car class and it has an inner Engine object. Another Driver class pushes to the gas pedal and just wants the Car move, it does not care how the Engine is implemented, which gives the car designers flexibility to design the engine, as soon as they obey the rules about designing an engine they can put whatever engine they want on the car. If the drivers knew more about how the engine works, like some internal properties and functions of it, and say some Drivers started using those functions, then in the next car design now the designers do not have the the same level of flexibility, they need to know functionalities of the Engine the drivers are using, how they use it and provide those as they are used, otherwise the Drivers will need to change behavior.

For the domain object example, assume we have a Student object. The Enrollment object and PaymentPlan object needs to access to this object. Even if you have usage of List<Student> students in another class, you want to make Student a public class outside of that class, not make it public in it.

Question's not really about scope/visibility of the POJO. It's really about the choice of making it a static inner class vs a regular inner class. — AlphaNumerical, Mar 04 '19 at 03:13
I would think very rare cases that one needs to create a public inner class. If that will be used other places, first question is why will it be an inner class? — mcvkr, Mar 04 '19 at 03:15
oh sorry misunderstood what you mean please see https://stackoverflow.com/questions/70324/java-inner-class-and-static-nested-class — mcvkr, Mar 04 '19 at 03:32
Thanks for that. Most important thing from that thread is this answer "Favor static member classes over non static" But that's goes along the lines of accessibility/ scope constraints -- more related to design principles. But from JVM's point of view, what's the implication of having a code that generates a series of static POJOs (I edited my question to add a code block to make this obvious). Thanks! — AlphaNumerical, Mar 04 '19 at 03:40

score 1 · Accepted Answer · answered Mar 04 '19 at 03:51

My thing is, which is better? 10 new static objects or 10 new regular java objects?

I'm trying to approach this from JVM's point of view - i.e. with a focus on performance. Not really about design/accessibility of objects according to Java OOP principles.

A static member class can be regarded as an ordinary top level class that just so happens to be nested within an enclosing class. In almost every way that matters to the JVM, a static member class is a top level class.

From a performance perspective, one can expect the performance of a static member class to be identical to the same class written as an actual top level class. Instances of static member classes are independent of their enclosing class and do not require an enclosing class instance in order to be instantiated.

Is it a good idea to use static inner classes in Java as POJOs

2 Answers2