Inner classes extending outer classes

[ivory wing]

i am missing the correct keywords to search the net. how do i find information on why inner classes extending outer classes inherit other inner classes. Basically i am curious why this compiles

class Scratch {

    interface outer {
        interface inner1 extends outer {}
        interface inner2 extends outer {}
    }

    public static void main(String[] args) {
        System.out.println(outer.inner1.inner1.inner1.inner1.inner2.class);
    }
}

[safe obsidian]

Detected code, here are some useful tools:

Formatted code

class Scratch {
  interface outer {
    interface inner1 extends outer {
    }
    interface inner2 extends outer {
    }
  }
  public static void main(String[] args) {
    System.out.println(outer.inner1.inner1.inner1.inner1.inner2.class );
  }
}

<@&987246399047479336> please have a look, thanks.

[topaz cloak]

I've never seen this before and also would've assumed it to just fail. The fact that this even compiles is crazy.

If anyone knows the answer, please ping me, too

Maybe this could actually be something more appropriate for #expert-java-talk , not sure

[wild cave]

Why would it not compile? If you implement any of your interfaces, you wouldn't have to implement that interface's subinterface.

[oblique vector]

The interface Scratch.outer.inner1 is not an 'inner' class of Scratch.outer (it's not even a class), it's a nested interface. Nesting has no inheritance relationship - just visibility and namespace.

interface Scratch.outer is similarly not an inner class of Scratch, it's a nested interface.

[ivory wing]

yeah, sorry for the bad example code. The question remains why the namespace gets "inherited". I know it is the wrong word. Exampe corrected to match the original question

class Scratch {

    static class S1 extends Scratch{

    }

    static class S2 extends Scratch{

    }

    public static void main(String[] args) {
        new Scratch.S1.S2.S1.S2.S1();
    }
}

Is there a way to "forbid" the strange namespacing

[safe obsidian]

Detected code, here are some useful tools:

System out

[Nothing]

[oblique vector]

Really this is just a technically valid, but not idiomatic, way to resolve the same type.

There's a suggestion of this in the JLS (maybe 6.5.5.1/6.5.5.2).

If at any point the names were not unique within their context, an error would occur. But otherwise it just collapses down to the single uniquely resolved type.

This is more quirk than intent.

[ivory wing]

Indeed, its just that since its techincally valid the autocompletion of ide's are sugesting such completions and i would like to streamline the api as much i can.

[wild cave]

A linter

[ivory wing]

at least spotless-palantir does not complain on this:

    class TestClass extends AppFeature.Async.Sequential.Async.Sequential {

        public TestClass(Class<? extends Feature> featureType) {
            super(featureType);
        }
    }

[safe obsidian]

Detected code, here are some useful tools:

[swift patio]

This compiles because in Java, when an inner interface extends an outer interface, it inherits all of the outer's members, including its inner interfaces. So, outer.inner1.inner1 refers back to outer.inner1, creating a chain that Java resolves without issue. It's an odd but valid quirk of nested interfaces and inheritance.

[wild cave]

I'm not sure if you can reference the subclasses of a base class from the base class's child class?

[wanton spade]

what ur saying there isnt true btw

interfaces are not classes

they behave differently

[wanton spade]

what ur writing there isnt really a showcase of who extends what and whatever

its more a showcase of how static access works

the full name of the interface inner2 is Scratch.outer.inner2

similar to static nested classes

when u write all that other stuff its essentially just replaced cause it all points to the same place

the reason "why" it compiles despite being "odd" is more due to quirks of how the JLS defined the rules

there is no convincing reason to "why"

but it has no real consequences in ur daily life. u wont be able to bring up a situation in which anything like that causes trouble or where u will actually see sth like that in practice

and, as said, the example is not related to who extends what