mgmt azure-json, `fromJson` cannot access read-only property from `Resource`

[XiaofeiCao]

Issue

• part of [FEATURE REQ] investigate enable stream serialization for mgmt azure-sdk-for-java#38333
• also discussed in Support azure-json in azure-core-management azure-sdk-for-java#38322 (comment)
• withId() is generated in fromJson implementation, despite that it's not present on Resource or ProxyResource
• id, name, etc... in Resource cannot be accessed in child classes

Current generated code:

if ("id".equals(fieldName)) {
    deserializedDedicatedHostGroupInner.withId(reader.getString());
} else if ("name".equals(fieldName)) {
    deserializedDedicatedHostGroupInner.withName(reader.getString());
} else if ("type".equals(fieldName)) {
    deserializedDedicatedHostGroupInner.withType(reader.getString());
}

Proposals:

Solution 1: Add protected setters in Resource/ProxyResource

Pros

1. Seemingly the most simple to implement. In fact, current codegen's working like magic as it assumes setter methods on parent classes. There's not much(if not none) codegen work involved.

Cons

1. Protected setter methods are exposed though all Resource/ProxyResource's subclasses.

Solution 2: Add protected constructors in Resource/ProxyResource

Pros

1. Exposed less amount(1 vs 3) protected methods than the setter
2. Preserves the "read-only" nature of these properties, compared to "setter"

Cons

1. Protected constructor is exposed any way.
2. mgmt doesn't have constructors with parameters for now
3. Way more things to implement than protected setters.

Solution 3: Shadowing id, name, etc... in child classes, similar to #2639

Pros

1. No unnecessary exposed methods/properties
2. No core dev work
3. Potentially consistent with general case: mgmt azure-json, in fromJson, sub class cannot call package-private setters on read-only properties of child class that's in a different package #2741

Cons

1. Duplicated shadowing properties across all inheritance hierarchy, making subclasses potentially cumbersome.
2. More dev work in codegen than protected setter approach.

Solution 4: Move ProxyResourceAccessor out of implementation package

Pros

1. No exposed protected methods/constructors

Cons

1. Violates the Accessor Helper design, where the helper should be in implementation.

Access helpers are defined in implementation packages and should be defined in the package implementation.accesshelpers

2. Similar as above, instead of exposing protected methods, it exposes unnecessary public Accessor Helper class.

Personal preference

From API's perspective, I prefer solution 3, which is the shadowing approach. It doesn't expose unnecessary APIs. Additionally, this may be consistent with the general case #2741, e.g. if the property is from parent and no public setter available, we shadow/duplicate it in child classes.
Haven't dived deep into each of the implementation. I assume all the solutions except solution 1(protected setters) involve getting some information of the base class(Resource/ProxyResource) to determine property's access pattern.

[weidongxu-microsoft]

My vote probably on 3 as well. But please also initiate the discussion in channel.