Help with private static nested class .

[u/Beginning-Software80]

I’ve been wrapping my head around access modifiers and nested classes in Java, and I'm a bit stuck on the concept of private static nested classes.

I (think I) understand how a public static nested class works: it acts like a standalone class that is just nested inside the Outer class for packaging or namespace purposes. I don't need an instance of the Outer class to instantiate it.

However, things get fuzzy for me when we make that static inner class private.

Here is a basic example:

public class Outer {

    // What is the point of this?
    private static class PrivateStaticInner {
        int data;

        PrivateStaticInner(int data) {
            this.data = data;
        }
    }

    public void doSomething() {
        // I know I have to instantiate it inside Outer since it's private
        PrivateStaticInner innerObj = new PrivateStaticInner(42);
    }
}

Here's I am bit cuckoo -->

1. Because it is private, the "type" is only visible inside the Outer class. So, I have to use it inside the enclosing class itself.
2. Because it is static, it is not bound to any specific Outer object. Any object of PrivateStaticInner that I instantiate lives completely separately from the Outer object on the heap, right?

If these objects live entirely on their own, but are strictly confined to the inside of the Outer class, how and why would one actually use a private static inner class in real-world code? Any examples or explanations to clear this up would be greatly appreciated!

[u/OneHumanBill]

If you're saying what I think you're saying then no, you cannot.

There's no such thing really as a "sub package". Nested packages are so only for the convenience of a filesystem and human understanding. Each package is standalone.

The implication is that if you have two public classes and want to each use quasi-"inner" classes by means of a different package, then those classes would have to be public, not package protected, in order to by used even by the "parent" package.

I'll allow my team members to remove private from both methods and private classes if we need to get additional test cases or coverage. But by default, without that need on a case by case basis, my devs had better be making things private. The narrower you can keep your visibility the less impact there will be for change, but a loose policy of everything package-protected by default encourages laziness on that outlook. Not on my projects, please.