proguard breaks usage

[darekxan]

Before everything works fine, calls return fine:
resolveRawArguments(Class type, Class subType)
resolveRawArgument(Class type, Class subType)

After proguarding the project (it is an Android project with no rules considering any particular classes related to the call) same call returns NPE.

I've already set:
-keepattributes Exceptions,InnerClasses,Signature,Deprecated,SourceFile,LineNumberTable,Annotation,EnclosingMethod
and it doesnt seem to help.

Do you have any hints how to create proper proguard settings?

I know its more of a proguard usage issue, but still - any hints welcome. Maybe someone had this problem and dealt with it already.

[jhalterman]

I've never tried pro-guard'ing it. Where are you getting a NPE? Can you post a stacktrace?

[darekxan]

NPE is in the line of call to resolveRawArguments.
Currently I cannot share any code, I'll provide test project until the end of week.

[csoroiu]

I got also an exception when i tried to resolve a lambda modified by retrolambda. The exception I got based on the 0.4.7 version was:

java.lang.ArrayIndexOutOfBoundsException: 48
        at net.jodah.typetools.TypeDescriptor.getArgumentTypes(TypeDescriptor.java:221)
        at net.jodah.typetools.TypeResolver.populateLambdaArgs(TypeResolver.java:328)
        at net.jodah.typetools.TypeResolver.getTypeVariableMap(TypeResolver.java:257)
        at net.jodah.typetools.TypeResolver.resolveRawClass(TypeResolver.java:239)
        at net.jodah.typetools.TypeResolver.resolveRawArguments(TypeResolver.java:176)
        at net.jodah.typetools.TypeResolver.resolveRawArguments(TypeResolver.java:136)
        at ro.derbederos.hamcrest.FunctionMatcher.map(FunctionMatcher.java:83)
        at ro.derbederos.hamcrest.LambdaMatchers.map(LambdaMatchers.java:111)
        at ro.derbederos.hamcrest.RetryMatchers.retry(RetryMatchers.java:149)
        at ro.derbederos.hamcrest.RetryMatchers.retryAtomicInteger(RetryMatchers.java:166)
        at ro.derbederos.hamcrest.RetryMatchers.retryAtomicInteger(RetryMatchers.java:183)
        at ro.derbederos.hamcrest.RetryMatchersTest.testRetryAtomicInteger(RetryMatchersTest.java:91                   

This is because the call constantPool.getMemberRefInfoAt() also returns for fields and constructors.

In the #28 pull request I also covered this case by filtering on methods. It could fix the issue, but it might not return the expected result with proguard (and does not work correctly with jacoco/intellij code coverage in combination with retrolambda for instance) they all change the constantPool and the heuristic used in the getMethodRefInfo method does not work correctly on all corner cases.