Hacker News Reader

Comment by smarks | Hacker News Reader

The article (which seems to be from 2026-04-24 based on its URL) refers to the JDK 26 version of the PEM Encodings API. [1]

[1]: https://openjdk.org/jeps/524

The article points out a potential pitfall with how this version of the API exposes a sealed class. If the application has an exhaustive switch expression that lists all permitted subclasses, and a later JDK release were to add a new permitted subclass, this would potentially expose the application to a MatchException at runtime.

In the JDK 27 version of the PEM Encodings API, JEP 538 [2], we’ve adjusted the permitted subclasses of the sealed class in question to include a non-public permitted subclass.

[2]: https://openjdk.org/jeps/538

This prevents applications from using an exhaustive switch expression by enumerating all permitted subclasses. This allows the JDK to extend set of permitted subclasses in the future without exposing applications to the risk of unexpected exceptions.

View on HN

It's a nice workaround but the necessity of such a non-obvious fix also shows that the design of sealed classes is really flawed ..

I disagree - the problem lies with the intention of exhaustively listing all available values in a switch expression with no backup plan. Switch expressions should always have a default/fallback branch, even if it's theoretically impossible and only logs the attempt/picks a default for future proofing the code and its uses.

> Switch expressions should always have a default/fallback branch,

This will nullify the advantage of being able to treat sealed classes as algebraic datatypes by using the exhaustiveness check.

Yes and no. You either accept that your code and the environment is final (in which case there's no problem and you can just blindly use the exhaustiveness check) or you accept that your code is a living thing that can change in part (including your edits, its dependencies, and its standard library), in which case you must be prepared for changes but can still make use of the exhaustiveness check by temporarily removing the default case.

I feel this is fundamentally a perspective issue. If this is a problem, also consider why people want sealed classes in the first place. It's always a tradeoff and you can also always fork or propose your own improved version of the concept and see if it has enough merit to gain traction. There's a million other footguns in the language that needs similar scrutiny, I'm just happy java isn't C/C++.

We could have both by introducing another keyword than "default" here.

In some cases you want "default" handling, in other cases it's a runtime detection of a code issue. E.g. you could add a "fallback" case which is the same as "default" yet if your code doesn't exhaustively handle all sealed class cases won't compile. This would still create a fallback, if your sealed class is widened later on, but still allow you to error out if it's already the case right now.

> You either accept

That is a false dichotomy. Some enumerations have reasons to likely change in the future, others (most) either have no such thing or their changing would be so impactful to the system it needs to be signaled loudly.

That’s really no different than any other type information.

> It's always a tradeoff and you can also always fork or propose your own improved version of the concept

You are the person asserting that the concept as defined is incorrect.

No, I assert that the concept as defined has a reasoning behind it that accepts certain tradeoffs for certain benefits. I think its perfectly valid to disagree with them, but I am curious about improvements to the current solution to the problem of extending types that really should not get extended (e.g. from the standard lib)

Not really.

Defaulting to exhaustive pattern matches is correct, it’s by far the most frequent case (which is why essentially every modern language does that); being able to prevent exhaustive matching is useful for libraries; and using a private subclass is a completely obvious way to implement that in Java.

See private extensible variants for the same capability in OCaml. Or the non_exhaustive attribute in Rust. Or the nonexhaustive attribute in Swift (or alternatively opting into library-evolution which reverses the defaults).

I’m glad you’ve fixed that issue. Hopefully you can fix the other design issues, including security weaknesses, I reported at the time [1]. I found the response rather dismissive and unhelpful, I have to say.

[1]: https://marc.info/?l=openjdk-security-dev&m=177435495515512&...

Reply on news.ycombinator.com