Closed eonj closed 4 years ago
This was an intentional change to fix some issues where the generic type can't be used (#108, #109). It was changed in #112.
It looks like this PR is effectively reverting that change and will cause those issues to regress.
@rharter Thank you, I read #112 changes and got it: you're right this PR is not sufficiently caring about the type wildcard or extends
/super
type bounds (as I said above). I'm glad to know that this kindof problem is already known, and also good to know why the UT's were also expecting the wrong type parameters.
My question is: do you have any plans for make right generic support again for the possible cases; or can you give me any instructions for alternative solution for correct generation?
After some months using this helpful AutoValue Parcel extension, I found that the current implementation is unparcelizing generic-typed fields in an inappropriate way. When a AutoValue declared class type
A
contains a field typedList<B>
, The generatedcreateFromParcel
usesreadArrayList
withClassLoader
of typeA
-- notB
.I tried to fix this problem in more broad and generous way -- for example, can we fix it with the map? Can we show an informatic message to the user when the type parameter is not a concrete bound but a
extends T
or asuper T
? Can we just warn the user instead of blowingjavac
with an unhandledAutoValueParcelException
?But I failed because I cannot read and change the whole code, so I submit a patch currently used (by my team). Thank you.