Repository navigation
Generics methods does not work #858
Description
Activity
I can confirm your issue using the latest snapshot.
I think the most easiest way to fix this and all generic-related issues is simply leaving the type parameter in the generated code.
So for this example:
@Override void foo(final Request bar) { }
You're right, but doing that removes the type constraint check for the arguments. My actual method has multiple arguments, each typed with
<T>. What I did to solve it was exactly what you suggested, but I had an extra "internal" method that wasn't type safe. Btw, since the@SuprressWarningsannotation isn't copied, AA will produce code with warnings. Not a big issue, but still annoying. It was made extra annoying because the foo method was implementing an interface method.@Override public <T> void foo(Request<T> bar, Listener<T> bar2) { } @Background @SuppressWarnings void fooInternal(Request bar, Listener bar2) { }
I think my previous comment was not clear. You should not remove the type parameter from your code, because you lost type safety, etc. (Well, i know you have no other option until this is not fixed some way). The generated class by AA should remove the type parameter - in case of the generated class, it does not matter, because types are already checked in your code. By the way some AA code will produce warnings, a discussion started about this in #835.
@DayS, what do you think on my suggestion about generic type?
It will not be easy to implement imho, as if you consider the following (for me common) case:
public class Bar { public <T extends Number> void foo(T x, List<T> y) { } } class Bar_ extends Bar { @Override public void foo(Number x, List y) { } }
I.e. you don't get around having to parse the generic type of the method, as the method requires that type for the input.
There are even worse cases like the following, but it should probably be considered rare and could possibly be left for later bug reports.
public class Bar { public <T extends Number & Serializable> void foo(T x, List<T> y) { } }
I think it should be easily enough to generate methods with provided generify types by doing only small changes. I already made a PoC and it seems to work fine.
But Codemodel currently doesn't provide a way to generate things like<T extends Number & Serializable>.Ho, about #838, this PR only handled method's params with wildcard. Named generics wasn't handled by this
I think this PR should resolve this issue. Could you confirm before I'm merging it ? I would like to release the 3.0.1 hotfix with this.
You didn't need a configured Eclipse to test it but you just have to do a
mvn clean installfrom the PR's branch and use 3.1-SNAPSHOT version in your (sandbox) project, as it'll be installed in your local maven repo :)Ok, i am on it.
Hmm, something is not ok. I just copied the jar from
AndroidAnnotations/androidannotations/targetfolder, and when APT ran, it saysNoClassFoundErroronEActivity. And the jar is only 374KB, the SNAPSHOT is more than 500.
Also the tests failed when running the functional tests, i guess because of this issue.AndroidAnnotations/androidannotationscontains only AA's core classes.
I think you may want to use the generated zip inAndroidAnnotations/androidannotations-bundle/targetCan you send me an email to continue this conversation there? I do not want to further pollute this thread.
Removed previous comment as it works perfect when the test case compiles.
#862 solves it for me, but I would appreciate it if you could add the following test case as well:
@Background <T extends Number> void parameterizedBackgroundMethod(final T param, final List<T> param2) { }
I can also confirm this works with the
858_namedGenericsbranch. Multiple bounds are still a problem, but that's expected. Also this very rarely-used Java feature still kills AA: :)@Background public void foo(List<? super Person> bar) { }
Great. Thanks for cross testing ;)
I suspect #838 will not fix the following, as there is no test case in it for this. Tested with AA 3.0 only, not 3.0.1.
Currently with AA 3.0 I get a name clash because the X_ class will contain:
(note the missing
<T>at the beginning>)--edit: fix last line
--edit2: removed
@Backgroundthat was not in the generated code