Skip to content
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
This repository was archived by the owner on Feb 26, 2023. It is now read-only.

Generics methods does not work #858

Description

@tobias-

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.

@Background
<T> void foo(final Request<T> bar) {
}

Currently with AA 3.0 I get a name clash because the X_ class will contain:

void foo(final Request<T> bar) {
}

(note the missing <T> at the beginning>)

--edit: fix last line
--edit2: removed @Background that was not in the generated code

Activity

  1. WonderCsabo commented on Jan 3, 2014

    @WonderCsabo
    Member

    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) {
    }
  2. tobias- commented on Jan 5, 2014

    @tobias-
    Author

    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 @SuprressWarnings annotation 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) {
    }
  3. WonderCsabo commented on Jan 5, 2014

    @WonderCsabo
    Member

    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?

  4. tobias- commented on Jan 5, 2014

    @tobias-
    Author

    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) {
        }
    }
  5. DayS commented on Jan 5, 2014

    @DayS
    Contributor

    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>.

  6. DayS commented on Jan 5, 2014

    @DayS
    Contributor

    Ho, about #838, this PR only handled method's params with wildcard. Named generics wasn't handled by this

  7. WonderCsabo commented on Jan 5, 2014

    @WonderCsabo
    Member

    @tobias- you are right, in that case, an Object replacement of T would not suffice, we would need Number. And in your second example, we could not replace the type parameter at all.

    @DayS Yes, as i already confirmed in my first comment, this issue is valid even in the latest snapshot.

  8. DayS commented on Jan 5, 2014

    @DayS
    Contributor

    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.

  9. WonderCsabo commented on Jan 5, 2014

    @WonderCsabo
    Member

    If @tobias- is busy i can check this right now, but only if you provide me a binary - i did not setup a building environment for AA (yet). On the other hand, of course i cannot check the original issue with @tobias- ' real code. :)

  10. DayS commented on Jan 5, 2014

    @DayS
    Contributor

    You didn't need a configured Eclipse to test it but you just have to do a mvn clean install from the PR's branch and use 3.1-SNAPSHOT version in your (sandbox) project, as it'll be installed in your local maven repo :)

  11. WonderCsabo commented on Jan 5, 2014

    @WonderCsabo
    Member

    Ok, i am on it.

  12. WonderCsabo commented on Jan 5, 2014

    @WonderCsabo
    Member

    Hmm, something is not ok. I just copied the jar from AndroidAnnotations/androidannotations/target folder, and when APT ran, it says NoClassFoundError on EActivity. 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.

  13. DayS commented on Jan 5, 2014

    @DayS
    Contributor

    AndroidAnnotations/androidannotations contains only AA's core classes.
    I think you may want to use the generated zip in AndroidAnnotations/androidannotations-bundle/target

  14. WonderCsabo commented on Jan 5, 2014

    @WonderCsabo
    Member

    Can you send me an email to continue this conversation there? I do not want to further pollute this thread.

  15. tobias- commented on Jan 6, 2014

    @tobias-
    Author

    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) {
    
            }
  16. WonderCsabo commented on Jan 6, 2014

    @WonderCsabo
    Member

    I can also confirm this works with the 858_namedGenerics branch. 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) {
    
    }
  17. DayS commented on Jan 6, 2014

    @DayS
    Contributor

    Great. Thanks for cross testing ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions