Inner classes

[Tim Bant]

Hey guys,

can someone help  explain 2 thing to me?

1) What is the point/purpose of a final inner class if you can't instantiate/extend it?

2) Why is a private abstract inner class permitted? Surely this should indicate that its private, so immediately no extending of it?

public abstract class Elephant {
	   abstract private class SleepsAlot {
	      abstract int sleep();
	   } }

[Mike Simmons]

Tim Bant wrote:1) What is the point/purpose of a final inner class if you can't instantiate/extend it?

There would be no point.  However, "final" does not prevent an inner class from being instantiated - it only prevents it from being extended.  So there can be a point, if you do instantiate the class.

(There could also be a reason to have a utility class, containing only static methods, which is usually made uninstantiable by design.  Though I've never seen a nested / inner utility class, and I can't think of a good reason to have one.)

Tim Bant wrote:2) Why is a private abstract inner class permitted? Surely this should indicate that its private, so immediately no extending of it?

public abstract class Elephant {
	   abstract private class SleepsAlot {
	      abstract int sleep();
	   } }

1. A private class could still be visible and / or extended by other code within the same top-level class..  The modified "private" only means private within the same top-level class.  (In the example shown, there is no other code in that same top-level class.  But there could have been.)

2. More importantly, when you have a private class that extends a public class, and instance of the private class is still an instance of that public class - which means, it can be passed on to other code that has access to the public class.  That outside code can't directly call any private method or private field that is only defined in the private class.  But, it can call any public method of the public base class - which can be overridden in the private class, and so can involve methods and fields in the private class.

Here's a simple example:

import java.time.Instant;

public class MysteryObjectSupplier {
  public static Object create(String name) {
    return new MysteryObject(name);
  }

  private static class MysteryObject {
    private final String name;
    private final Instant creationTime = Instant.now();

    public MysteryObject(String name) {
      this.name = name;
    }

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

public class MysteryObjectClient {
  public static void main(String... args) {
    Object a = MysteryObjectSupplier.create("Foo");
    Object b = MysteryObjectSupplier.create("Bar");

    System.out.println(a.toString());
    System.out.println(b.toString());
  }
}

Here the MysteryObject declaration is only visible inside MysteryObjectSupplier - it can't be seen or used by the MysteryObjectClient.  The Client only knows that it's getting an Object of some kind.  And yet, it still is able to call the toString() method, because that is public in the original Object declaration.  And so it is able to execute the code of toString() inside MysteryObject, which also uses the private name and creationTime fields.  So, even though the MysteryObjectClient only knows it's getting an Object, it's getting an Object that is actually a MysteryObject, with specific behavior and data fields that were in that private class.

[Tim Bant]

Thanks so much for the explanation! Makes total sense now
Cheers

[Tim Holloway]

Mike Simmons wrote: Though I've never seen a nested / inner utility class, and I can't think of a good reason to have one.).

Something like a collection of constant data. Say, conversion factors, formulas, a table of logarithms. Stuff that you could splatter about the insides of the containing class, but it's tidier to wrap them up in an inner class.

[Mike Simmons]

Yeah, makes sense.  Personally I would be more inclined to make that a top-level package-private class.  But I accept that there could be a situation where it makes sense to confine the scope within a single top-level class, not a package.