Glide: Compile error when use version 4.2.0----Error: RequestOptionsGenerator$1 cannot be accessed

[shfouc]

Glide Version:Glide 4.2.0 (https://github.com/bumptech/glide/releases)

Integration libraries:No

Device/Android Version:HUAWEI Mate9 7.0

Issue details / Repro steps / Use case background: compile Error: RequestOptionsGenerator$1 cannot be accessed
Error class file:... \libs\compiler-4.2.0.jar (com/bumptech/glide/annotation/compiler/RequestOptionsGenerator$1.class)
Class RequestOptionsGenerator$1 closed method property error
Please delete this file or make sure it is in the correct classpath.
Error: RequestOptionsGenerator$1 cannot be accessed
Error class file:... \libs\compiler-4.2.0.jar (com/bumptech/glide/annotation/compiler/RequestOptionsGenerator$1.class)
Class RequestOptionsGenerator$1 closed method property error
Please delete this file or make sure it is in the correct classpath.
1 mistakes

[TWiStErRob]

Can you try running gradlew with --stacktrace?

[shfouc]

@TWiStErRob I see some duplicate classes in compiler-4.2.0.jar, you can open it by WinRAR

[TWiStErRob]

Ah, I see, @sjudd it looks like both the proguarded and non-proguarded .class files were packaged in 4.2.0 for the apt.

[TWiStErRob]

@sjudd Took a quick look from zipTree(proguardedJar) only adds to the inputs of jar, doesn't replace, so the default sourceSets.main.output is still there, resulting in duped classes in final jar.

jar {
    duplicatesStrategy = DuplicatesStrategy.FAIL // a way to prevent regressing
    dependsOn proguard
    from zipTree(proguardedJar)
    // failed attempt to exclude all
    sourceSets.main.output.files.each {
        exclude "${it.absolutePath}/**"
    }
    // working attempt to exclude, but it may be resource intensive (complexity)
    exclude { entry ->
        sourceSets.main.output.files*.absolutePath.any {
            entry.file.absolutePath.startsWith it
        }
    }
    // another failed attempt, for some reason it doesn't match the files even though their absolute paths are the same
    exclude { sourceSets.main.output.contains(it.file) }
}

[sjudd]

Thanks for the report and thanks @TWiStErRob for looking in to it.

Do we know how to reproduce this error? I tried a sample app and just adding an AppGlideModule with the 4.2 glide and compiler dependencies doesn't seem to fail.

[TWiStErRob]

Not sure how to repro it, my aim was only to remove the duplication. What I did is just gradlew :annotation:compiler:assemble and check that ...\annotation\compiler\build\libs\compiler-4.3.0-SNAPSHOT.jar has no dupes.

@shfouc can you please share your Glide-related build.gradle lines (apt, compile, etc... )?
Also maybe which Android Gradle Plugin / Java / Gradle are you using.

[TWiStErRob]

@sjudd are you planning a 4.2.1 or mis-tagged this milestone?

[sjudd]

I might just replace the the 4.2 jars, there wouldn't actually be a code change, only a packaging change. Otherwise yes, 4.2.1.

[TWiStErRob]

I don't think replacing is a good idea, Gradle/Maven doesn't support re-fetching artifacts once they're cached locally (unless manually instructed). On GitHub it would be ok, but I doubt many users use manual downloads.

[sjudd]

Yeah that's a good point, 4.2.1 it is.

I'd love to figure out why my sample app isn't failing, even with the duplicates. It's hard to test the maven/gradle packaging and deployment generically, though catching this is relatively straight forward.

[sjudd]

Looks like I can also just do:

task jar(type: Jar, overwrite: true) {
    duplicatesStrategy = DuplicatesStrategy.FAIL
    dependsOn proguard
    from zipTree(proguardedJar)
}

which will avoid the efficiency issue with excludes (though it's probably not a big deal anyway). Took me forever to find that...

[sjudd]

Ah ok I can reproduce this, but only if I copy/paste the Glide jars into a libs directory. If I use the maven dependencies it works fine.

Here's the full error I see with glide-full-4.2.0.jar, annotation-4.2.0.jar, and compiler-4.2.0.jar pasted into the libs directory of my sample app:

judds-macbookpro2:testjarjar judds$ ./gradlew build
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:app:prepareComAndroidSupportAnimatedVectorDrawable2600Alpha1Library
:app:prepareComAndroidSupportAppcompatV72600Alpha1Library
:app:prepareComAndroidSupportConstraintConstraintLayout100Beta5Library
:app:prepareComAndroidSupportSupportCompat2600Alpha1Library
:app:prepareComAndroidSupportSupportCoreUi2600Alpha1Library
:app:prepareComAndroidSupportSupportCoreUtils2600Alpha1Library
:app:prepareComAndroidSupportSupportFragment2600Alpha1Library
:app:prepareComAndroidSupportSupportMediaCompat2600Alpha1Library
:app:prepareComAndroidSupportSupportV42600Alpha1Library
:app:prepareComAndroidSupportSupportVectorDrawable2600Alpha1Library
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
:app:generateDebugResValues
:app:generateDebugResources
:app:mergeDebugResources
:app:processDebugManifest
:app:processDebugResources
:app:generateDebugSources
:app:incrementalDebugJavaCompilationSafeguard
:app:javaPreCompileDebug
:app:compileDebugJavaWithJavac
error: cannot access RequestOptionsGenerator$1
  bad class file: /Users/judds/opensource/glide_test_projects/testjarjar/app/libs/compiler-4.2.0.jar(com/bumptech/glide/annotation/compiler/RequestOptionsGenerator$1.class)
    bad enclosing method attribute for class RequestOptionsGenerator$1
    Please remove or make sure it appears in the correct subdirectory of the classpath.
error: cannot access RequestOptionsGenerator$1
  bad class file: /Users/judds/opensource/glide_test_projects/testjarjar/app/libs/compiler-4.2.0.jar(com/bumptech/glide/annotation/compiler/RequestOptionsGenerator$1.class)
    bad enclosing method attribute for class RequestOptionsGenerator$1
    Please remove or make sure it appears in the correct subdirectory of the classpath.
1 error
:app:compileDebugJavaWithJavac FAILED

[shfouc]

Limited by my company, i can not use maven.

[sjudd]

Ugh and although replacing the task seems cleaner, it would require figuring out how to replicate all of the task dependencies, which seems like it's going to be more work and less future proof than just using excludes.

I also confirmed the jar on maven central has duplicate entires as well. I'm not sure why building with gradle with a jar on maven with duplicate class entries works, but building with gradle with a local jar with duplicate class entries fails.

However, unless we can reproduce the failure using the maven central dependencies, I'll target this to 4.3. I'll upload a new compiler-4.2.0 jar to GitHub for now built from the 4.2.0 but with the duplicate class files removed.

[sjudd]

Jars are updated here: https://github.com/bumptech/glide/releases/tag/v4.2.0

[shfouc]

It works. Thanks you very much @TWiStErRob @sjudd

[TWiStErRob]

@shfouc

Limited by my company, i can not use maven.

How do you compile then? I can't imagine building an Android app without dependency management/build tool.

@sjudd it bugs me as well, why it "just works". The error comes from javac, so my guess is that @shfouc is using a different JDK to compile or simply the Gradle and the manual/other call to javac has different args.

overwrite: true replaces the whole task, that's indeed trickier. I was looking for mainSpec.reset(), but could find that API. (Tip: in IDEA you can use "Navigate to" action on the token exclude to see how it works.) If all you wanted is restore dependencies, you can probably do def deps = jar.dependsOn; task jar(type: Jar, overwrite: true, dependsOn: deps){...}, and hope that assemble dependsOn "jar" and not the actual old task object.