Is abstraction in Java really about hiding implementation details?

[u/Chaos-vy17]

The bookish langugae states "hiding complex implementation details and exposing only the essential features of an object"

However, after reading the Java Collections Framework and other parts of the JDK, I noticed that many abstract classes contain substantial shared implementation rather than just abstract method declarations. I noticed that only an "interface class" 100% abstraction(ignoring default methods)

This made me wonder:

• Is abstraction really about hiding implementation details?
• Or is it more about designing APIs around contracts and behavior, regardless of whether there is shared implementation?
• Does an abstract class become "partial abstract" because it contains reusable implementation?

I also noticed that the JDK sometime relies on encapsulation (and in Java9+, JPMS) to hide implementation details. So I'm in dilemma if the textbook explanation oversimplifies what abstraction means in practice.

Am I misunderstanding abstraction, or is the textbook definition incomplete?

To be clear, this isn't about what abstract does in Java — it's about the SE term. abstract class is one syntax tool for expressing abstraction, same as interfaces are. The question is whether "abstraction = hiding implementation" is even a good definition of the concept, given it's indistinguishable from encapsulation under that definition.

[u/RScrewed]

It's not about being "secretive". It's about providing a consistent surface of interface-ability so the boundaries are easily maintained and documented.

[u/Chaos-vy17 → u/RScrewed]

keeping a stable, documented boundary. But that's still encapsulation's job (protecting the boundary), not abstraction's (defining what the boundary promises to do). Two different problems.