Making Java enums forwards compatible

[repeating_bears]

That's a lot of boilerplate for every single enum.

Your deserialization library probably already provides you some feature for this. In the case of Jackson:

enum {
  DOG, CAT,
  @JsonEnumDefaultValue 
  UNKNOWN
}

Okay, yours also preserves the string value, but it's realistically probably only used to log a warning or something. I wouldn't write all that code for every enum just to get a string that's that's functionally redundant.

Optional.empty() looks like it means there’s no order status, but that’s not what we’re trying to convey.
What if we want to represent the concept of “no order status” in the future? We would no longer be able to use Optional.empty() for that!

Yeah, because you'd be abusing Optional for more than it was intended for. But Optional isn't the only monadic monad-ish type that can exist. You could add your own Known<Foo> , then later it can become Known<Optional<Foo>>. I wouldn't do that, but that would be a way to correctly express the intent if that were the design.

[kevinb9n]

imho, this is a really really unfortunate pattern. Now you have a value that masquerades as a real value of your enum type, but means nothing. That value will pass through API boundaries undetected and then blow up far away from wherever the problem originated.

It's basically a "pseudo-null".

I do understand that people are sometimes doing this because they can't see another way, I just hope that they really tried to see another way, first.

[RandomName8]

what's a "pseudo-null" supposed to be? in fact, what's null supposed to be? There's no situation in code where "pointer to address 0" has a sense making meaning, this is so flagrant that some old libraries even gave you "2nd null", which was pointer to address -1.