You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given an Application class with a generic superclass, Hilt inserts the Hilt_ application class into the hierarchy but the signature attribute annotation is not updated with the new superclass. Is this intended behaviour or a bug?
Example:
open class BaseApplication<T> : Application()
@HiltAndroidApp
class MyApplication : BaseApplication<String>() {
override fun onCreate() {
super.onCreate()
println(this.javaClass.superclass)
println(this.javaClass.genericSuperclass)
println(this.javaClass.genericSuperclass.typeName)
}
}
Without Hilt:
.class public final Lcom/example/hiltexample/MyApplication;
.super Lcom/example/hiltexample/BaseApplication;
# annotations
.annotation system Ldalvik/annotation/Signature;
value = {
"Lcom/example/hiltexample/BaseApplication<",
"Ljava/lang/String;",
">;"
}
.end annotation
class com.example.hiltexample.BaseApplication
com.example.hiltexample.BaseApplication<java.lang.String>
com.example.hiltexample.BaseApplication<java.lang.String>
With Hilt the superclass in the signature attribute doesn't change and therefore doesn't match the actual superclass anymore:
.class public final Lcom/example/hiltexample/MyApplication;
.super Lcom/example/hiltexample/Hilt_MyApplication;
# annotations
.annotation system Ldalvik/annotation/Signature;
value = {
"Lcom/example/hiltexample/BaseApplication<",
"Ljava/lang/String;",
">;"
}
.end annotation
class com.example.hiltexample.Hilt_MyApplication
com.example.hiltexample.BaseApplication<java.lang.String>
com.example.hiltexample.BaseApplication<java.lang.String>
The text was updated successfully, but these errors were encountered:
mrjameshamilton
changed the title
Incorrect signature attribute?
[Hilt] Incorrect signature attribute?
Dec 6, 2021
…s parameterized types.
When an Android entry point has a superclass that uses parameterized types then the Class file will contain a Signature attribute that also has to be updated since the super_class is changed via Hilt's transform. The attribute is not checked by the JVM during linking, which is why it had not caused any issues before, but it does affected certain reflective APIs. See: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.9Fixes: #3094
RELNOTES=Fix an issue where Hilt transform was not correctly updating the Signature attribute of an @androidentrypoint whose superclass contained a type variable.
PiperOrigin-RevId: 414441547
…s parameterized types.
When an Android entry point has a superclass that uses parameterized types then the Class file will contain a Signature attribute that also has to be updated since the super_class is changed via Hilt's transform. The attribute is not checked by the JVM during linking, which is why it had not caused any issues before, but it does affected certain reflective APIs. See: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.9Fixes: #3094
RELNOTES=Fix an issue where Hilt transform was not correctly updating the Signature attribute of an @androidentrypoint whose superclass contained a type variable.
PiperOrigin-RevId: 414441547
Given an
Application
class with a generic superclass, Hilt inserts theHilt_
application class into the hierarchy but the signature attribute annotation is not updated with the new superclass. Is this intended behaviour or a bug?Example:
Without Hilt:
With Hilt the superclass in the signature attribute doesn't change and therefore doesn't match the actual superclass anymore:
The text was updated successfully, but these errors were encountered: