The purpose of $Hidden union memeber

[timocov]

Currently for unions (and I guess for enums as well) the codegen generates sealed interface with all variants as sub-classes (records) implementing this sealed interface, which makes the use of such unions type-safe so that's amazing! But what I found a bit interesting is that at least for unions, there is also a private class being created, that is not used anywhere, but it blocks the usage of switch/case on type because the class is hidden and it is not possible to use it in case clause. Can you elaborate what is the purpose of this $Hidden class being generated but not accessible?

Basically for the following smithy model:

structure Payload {
    testUnion: TestUnion
}

union TestUnion {
    first: FirstStruct
    second: SecondStruct
    third: ThirdStruct
}

and the java code:

        switch (input.getPayload().getTestUnion()) {
            case FirstMember fm -> fm.first();
            case SecondMember sm -> sm.second();
            case ThirdMember tm -> tm.third();
            case $Unknown unknown -> {
            }
        }

I'm getting switch' statement does not cover all possible input values error because I didn't cover $Hidden case 🙁

[adwsingh]

I'm getting switch' statement does not cover all possible input values error because I didn't cover $Hidden case 🙁

Its exactly for this case to force customers to add a default branch so that adding new union variants which are a backward compatible change doesn't break existing Java code.

[timocov]

to add a default branch so that adding new union variants which are a backward compatible change doesn't break existing Java code

Isn't handling $Unknown for this problem (at least in runtime)? 🤔 Or when you say "doesn't break existing Java code" you meant "the code still compiles"? If so, would it be possible to have a setting that would change this behavior? From what I see, having this for the client codegen potentially might make sense (even tho I'd prefer to highlight potential problems in customer's code rather than silently swallowing it with the default branch - at least I'd prefer this option for my clients/servers), but for servers where such value is the source of truth (when it is), it doesn't feel that much practical and only hides issues when you change the model.

[timocov]

For instance, when I add a new union/enum member in the model, I would expect the compilation to fail in all places where I didn't check this new member yet so that it would help me to identify all of the places where I need to add extra handling. The same would apply to consumers with clients - whilst existing deployments would still handle a new value (via unknown handling), when you pull in a new client this would give you an indication if you need to update your business logic to handle extra values, without reading the model and trying to understand which enums/unions have changed so that you can go over all of them and validate that the handling is still correct. 🙂

[mtdowling]

Smithy's spec explicitly calls out that unions and enums are open and not a breaking change to expand them. Breaking compilation would be a breaking change and prohibitive for environments that do dry-run style builds to deploy software. So the approach in this library is that you need a default case to handle unknown variants (e.g., getMemberValue), or ignore and log them. Gonna close this as something we won't be able to change.