IssueTracker

merged ot master, cherry pick CL ready for 3.5 and 3.6 branches

This issue blocks us from update to AGP 3.5.1. Hope we will get 3.5.2 soon

Is it already in 3.6 beta 1?

no should be the next one and 3.7 canary and if 3.5.2 if it ever exists.

This is still an issue for me on 3.6.0-beta02

can you create a sample that reproduces the problem?

I'm also still getting it in  3.6.0-beta02.

just to double check w/ cherry-picks, can you also try w/ 4.0 ?

Still the same issue with AGP 4.0-alpha01,

I have a ViewModel that looks like this:

MyViewModel<out T : FooModel, P : BarModel<T>>

Hi yigit, i still got similar issue on 3.5.2 (while it was working fine on 3.5.0)  . Please find my sample project for the detail. it is error on checkbox that using generic class.

CheckItem<CAP#1>> cannot be converted to List<RadioCheckItem<?>>
                    viewModelRadioCheckItems = viewModel.getRadioCheckItems();
                                                                           ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object from capture of ?
1 error

Thanks for the sample #11.
You can fix your problem by giving a type reference to the variable, something like:

<data>
        <import type="android.view.View"/>
        <variable
            name="viewModel"
            type="com.test.myapplication.RadioCheckViewModel&lt;Object>"/>
    </data>


I'm looking into what we can do but the main problem here is that data binding doesn't have enough information (any type bound for the variable) and when the guess it makes is bad, it fails the code.
We've made some changes to make that guess better which broke your use case :/
I'm basically trying to find the best balance that'll break fewer people but prioritize cases where things were declared more strongly (e.g. variable having type arguments defined or class description having an upper bound).

re-opening to address the new sample.

Thanks Yigit for the workaround, now I finally understand that issue happens because we use raw generics in binding layout. Now I declare data for my view model with the most generic type and everything is fine.

glad it is resolved.
Honestly, by not being strict on these things in the first data binding version; we've cornered ourselves such that any change breaks someone.
I actually had a fix for yours which break another test (luckily, at this point we have accumulated a lot of tests for these issues).

So i'm not sure if we'll be able to find a "fix" for this since it mostly means behavior change at this point and ends up breaking someone else.
Since yours does have an easy workaround, we might stick w/ current behavior.
(I even tried changing data binding to automatically apply that workaround but then it fixed yet another test :shrug:)

Thanks yigit, the workaround also working for me. Actually it only breaks one class, so it very rare case for us to use generic on databinding.

> we might stick w/ current behavior
I think it's completely fine (and actually good) to restrict raw types, but it should be a proper error message, not the generation of invalid Java code as it done now

decided to to leave it as is since adding types break other cases if there is an adapter that did not specify type.