4

In most of the cases I've seen that nested classes are static.

Lets take an example of Entry class in HashMap

static class Entry<K,V> implements Map.Entry<K,V> {
    final K key;
    V value;
    Entry<K,V> next;
    final int hash;

    .....
    .....
}

Or Entry class of LinkedList

private static class Entry<E> {
    E element;
    Entry<E> next;
    Entry<E> previous;

    .....
    .....
}

What I know so far about nested class is: 

- A non-static nested class has full access to the members of the class 
  within which it is nested.

- A static nested class cannot invoke non-static methods or access non-
  static fields

My question is, what is the reason for making a nested class static in HashMap or LinkedList?

Update 1: 

Following the already answer link I got an answer - Since And since it does not need 
access to LinkedList's members, it makes sense for it to be static - it's a much 
cleaner approach.

Also as @Kayaman pointed out: A nested static class doesn't require an instance of 
the enclosing class. This means that you can create a HashMap.Entry by itself, 
without having to create a HashMap first (which you might not need at all).

I think both these points answered my question. Thanks all for your input.

Kartic
  • 2,935
  • 5
  • 22
  • 43

2 Answers2

2

A nested static class doesn't require an instance of the enclosing class. This means that you can create a HashMap.Entry by itself, without having to create a HashMap first (which you might not need at all).

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • So, is it always a good practice to make nested class static (and may be private)? – Kartic May 11 '15 at 08:54
  • 2
    @Kartic - Nope. Not *always*. I usually steer clear of *nested classes* unless they are *really required*. Nested classes are used based on *design decisions*. `Entry` is a *nested class* because other classes like `Arrays` also have their own *definitions* of `Entry`. *Static nested classes* are usually used for (packaging concerns) making your code *more readable* – TheLostMind May 11 '15 at 08:58
1

1) Because it is not needed from the "outside": it is only used by the enclosing class. By making it a private inner static class, this intention is obvious.

2) By being an inner class, it automatically has access to all private fields of the enclosing class, so there is no need to create getters or worse like making them package private or protected.

And why make it static?

Non-static inner classes need a reference to an instance of the enclosing class. If the inner class is static, this is not needed: instances of static inner classes don't have a reference to the enclosing class. They can be created without an instance of the enclosing type and they can live without it.

In case of non-static inner class, the instance of the enclosing class is sometimes transparent (e.g. when you instantiate the non-static inner class from a non-static method of the enclosing class, it is this), or can be explicit, e.g.:

EnclosingClass ec = new EnclosingClass();
InnerClass ic = ec.new InnerClass();
icza
  • 389,944
  • 63
  • 907
  • 827