I understand that sealed interfaces (and sealed classes) allow the compiler to perform exhaustive checks for pattern matching and switch expressions, which is a clear improvement in type safety at compile time.

However, I’m trying to understand the runtime impact. Specifically:

• Does the JVM (especially HotSpot) apply any dedicated optimisations when it encounters a sealed interface, compared to a regular, non‑sealed one?

• For instance, does the JIT compiler actively use the PermittedSubclasses attribute to make inlining, devirtualisation, or class‑hierarchy analysis (CHA) more aggressive or more stable?

• Or is the reality that sealed interfaces only enforce a contract at compile time, and at runtime they are treated exactly like any other interface (subject to the same standard CHA and de‑optimisation strategies)?

In other words, is there any measurable performance gain because an interface is sealed, or is the benefit solely the compile‑time exhaustiveness guarantee that prevents bugs?