It’s important to not conflate Java’s interface keyword with the more general notion of “interface” as in “API”. In Java, you generally don’t and can’t have a source-level representation of the API without it being interspersed with its implementation.

(You could imagine such a representation, i.e. remove all method bodies and (package-)private elements, but the result wouldn’t be valid Java. IDEs arguably could and should provide such a source-level view, e.g. via code folding, but I don’t know any that do.)

Even as a java programmer, I think this is a bad take. Java doesn't force separation of implementation and interface, and java interfaces also have a lot of weird stuff going on with them.

Java also has too many tools for this. You both have class/interface, but also public/private. I honestly think C does it better than Java.

> java interfaces also have a lot of weird stuff going on with them.

really? I know java pretty well, and there aint nothing weird there.

C uses conventions to produce an "interface" (ala a header file with declarations). Java uses compilers to produce an interface, which i do really like. You can ship that interface without an implementation, and only at runtime load an implementation for example.

> You both have class/interface, but also public/private.

And these are all othorgonal concerns. A private interface is for the internal organization of code, as opposed to a public one (for external consumption). That's why you might have a private interface.

> C uses conventions to produce an "interface" (ala a header file with declarations). Java uses compilers to produce an interface, which i do really like. You can ship that interface without an implementation, and only at runtime load an implementation for example.

You can do this in C as well, since it has separate code declarations and definitions. You conventionally put the declarations in the header and definitions in the source file. A C program can link against declarations alone, and the implementations can be loaded later using dynamic linking.

> And these are all othorgonal concerns. A private interface is for the internal organization of code, as opposed to a public one (for external consumption). That's why you might have a private interface.

But these are profoundly overlapping concerns. Interfaces also hide the internal organization of the code, and on top of this, you also have project jigzaw's modules (that absolutely nobody uses), but which also caters toward separating private implementations from public interfaces.

Absolutely not.

you don't like java interfaces?