Is it ever reasonable to nest Java inner classes more than one level deep?

Question

Kushal Paudyal asked how deep you can nest inner classes in Java. The consensus is that while the language itself imposes no limit, the underlying OS and file system may.

Have you ever found a case where two or more levels of nested inner classes are helpful?

Update (11/28): If you consider enum classes, a second level of nesting can make sense. During some recent refactoring, I briefly had an outer class (an HTTP client), an inner class (an in-memory cache), and inside the inner class an enum class (for the cache eviction strategies). This seemed okay, but to @Thorbjørn's point, I continued by extracting the cache class and its inner enum up out of the HTTP client class.

Answer 1

I have not personally run into a case where more than one proved necessary. I could forsee a case where two may prove useful. I have trouble imagining more than two however.

The example I'm imagining is in Java GUI code. It may be useful in certain circumstances to have a class nested inside an already nested ActionListener.

Answer 2

No. I have not.

The standard example of a class inside a class is the Builder, where you have a subclass to help create a proper instance given a lot of possible configuration methods.

Personally I would consider a more complex case of nested classes an excellent example of code which needs refactoring.

Answer 3

Sure - this is valid sometimes. I just did some a few minutes ago.

For example, in some test code I wrote, I wanted to set up some boilerplate that handled running multiple callables. The boilerplate needed to create multiple instances of a callable chunk of code. In this example, I'm creating an instance of a factory to pass into threadedTest, and that factory creates new callables.

@Test public void testXXXXXXXX() throws Throwable {
    threadedTest(new CallableFactory() {
        @Override public Callable<Request> create() {
            return new Callable<Request>() {
                // might have state
                @Override public Request call() throws Exception {
                    // do the steps for this test
                    return ...;
                }};
        }});
}

Much more concise than creating two new classes where one just creates the other. Of course there's a readability penalty here until you're used to the style, though...

If you combined this with a template method to control transactions or database connect/close, this could end up three deep. (I've had some code like that; if you do it, make sure you write a dummy sample in your comments and explain the structure well)

Answer 4

If you're generating code from some data, nested classes can be a good way of avoiding name collisions.

Answer 5

I saw usage of number of levels of nested classes.

There is a legacy machine named Tandem (of HP), that originally runs code of COBOL/C. There are later "patches" that enable that machine of running java too. The variables structure of COBOL are naturally multi-leveled (even 5 levels is a common case), so in order to allow java to call to COBOL servers the java classes were also multi-leveled in order to simplify the conversion of the data between them.

I agree that this is a very uncommon case, but anyway...