[MDSAL-330] Mapping type collisions between yang built-in uint* and int* Created: 03/Apr/18 Updated: 18/Nov/19 Resolved: 06/Sep/19 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding codegen |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0 |
| Type: | Bug | Priority: | Medium |
| Reporter: | Jie Han | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
module test-unoin-types {
namespace "urn:test:pattern";
prefix union-types;
revision 2018-04-03;
container cont {
leaf test {
type union {
type int8;
type int16;
type int32;
type int64;
type uint8;
type uint16;
type uint32;
type uint64;
}
}
}
}
e.g. int16 and uint8 both map to java.lang.Short that leads to constructors conflict. |
| Comments |
| Comment by Jie Han [ 03/Apr/18 ] |
|
We may use yang.common.Uint* instead of java.lang.* for yang uint*, but it may break compatibility in binding v1, that should properly be improved in binding v2. |
| Comment by Robert Varga [ 03/Apr/18 ] |
|
Yeah, Binding V2 can use those, as that is the long-term move for NormalizedNodes. For V1 we'll need to do the same – but not in this cycle, I am afraid. |
| Comment by Jie Han [ 09/Apr/18 ] |
| Comment by Robert Varga [ 05/Sep/19 ] |
|
We still need to update ClassGenerator to emit compatibility constructor for Key classes, i.e. non-value-wrappers. These potentially have a large number of arguments, so could lead to combinatorial explosion. We will deal with this by just creating one legacy constructor with all arguments converted. |