Accidental override: The following declarations have the same JVM signature

Question

I'm getting error in Kotlin in this part:

class GitHubRepoAdapter(
    private val context: Context,
    private val values: List<GithubRepo>
) : ArrayAdapter<GithubRepo>(
    context, 
    R.layout.list_item,
    values
)

private val context: Context

In the log it says:

Error:(14, 25) Accidental override: The following declarations have the same JVM signature
(getContext()Landroid/content/Context;):  
    fun <get-context>(): Context  
    fun getContext(): Context!

I'm not able to see what is causing the problem.

Lefkowitz

May be this would be helpful #29269026 – Civility

Answer 1

This happens because the Kotlin compiler tries to generate a getter for val context declared in your class primary constructor, namely a method getContext(), but the base class ArrayAdapter<T> already has such a method.

You can solve that by doing one of the following:

• Change your class' constructor parameter not to be a val.

     class GitHubRepoAdapter(context: Context, ...
  

  In this case, the getter won't be generated, and the conflict will be gone.

  This seems to be the preferrable solution in your case, because, even without redeclaration, there is already a synthetic property context inferred from the Java getter.

• Use the @JvmName annotation, apply it to the context property getter:

     class GitHubRepoAdapter(@get:JvmName("getAdapterContext") private val context: Context, ...
  

  This will make the compiler generate the getter with another JVM name (the one specified in the annotation), thus avoiding the conflict, but making accessing it from Java less intuitive (especially since there will be two similar functions). In Kotlin, you will still be able to use the property with its original name context.

Cowling

Is this working with val properties inherited from interface? I mean for example interface with val context: Context? – Inwards

Answer 2

In addition to the answer already given...

• Or, you can keep val (or var) but change the name of the parameter to something that doesn't collide with the super class declaration.

In a class declaration, the parameters in the constructor declarations are often more than just parameters. Using val or var, you are actually declaring property members (not just parameters). And along with the property members come automatic "getters" (and "setters" in the case of var). The automatic getter, in the OP's case, is called getContext() but the base class already has a getContext() (same signature).

Most likely, the intent here was to just pass the context to the super, in which case, the other answer works best. But, in the case where a new property is desired, but the name chosen collides with a differently purposed member of the super, changing the name is the alternative.

In short, changing the name applies when you do want a new member variable but a super class already exposes a different member by the same name.

Theall

I think this version is actually more preferable to the accepted answer. If my super class already has a property/getter/setter for a variable, why would I create a 2nd one at all? Removing val/var seems the slickest way to go for sure. – Brewhouse

@Brewhouse - you misunderstand my answer, mine actually says you can keep the val or var and just change the name of the variable, which is useful when the super class already uses the first name you chose. In the case where the super class uses the name for a property with an entirely different purpose than what you were planning for your variable, then a new property is appropriate using a different name. I will update my answer to make it more clear. – Theall

Best and simple answer unlike others. – Tillietillinger

Answer 3

I got a similar error I solved it by removing the null checks from the constructor parameter

From

fun onChildDraw(
    c: Canvas?,
    recyclerView: RecyclerView?,
    viewHolder: RecyclerView.ViewHolder,
    dX: Float,
    dY: Float,
    actionState: Int,

To

fun onChildDraw(
    c: Canvas,
    recyclerView: RecyclerView,
    viewHolder: RecyclerView.ViewHolder,
    dX: Float,
    dY: Float,
    actionState: Int,

Linear

The opposite worked for me. I suppose the full answer is that the types have to be the same whether they include or exclude null checks. – Thruster

Answer 4

Change variable name to myContext and will work with you without any problems.

Runty

Answer 5

I would like to add something here:

When you name your parameter as context it will collide with the base class parameter name which is also context by default. So changing the name of your parameter will help you.

Kenward

Answer 6

The return types of the two functions are Context and Context! which are two different things. To fix it, add the exclamation mark to your code.

Foreword

In my case, it was read(sink: Buffer? ... that had to be changed to read(sink:Buffer .... Thanks! – Helios

Answer 7

Had similar problems, what worked was ensuring that my targetSdkVersion and compileSdkVersion were the same across all modules.

Thadthaddaus

Answer 8

Building up on @hotkey's answer... In this particular example, I believe the reason is because OP does the following:

    private var _context: Context? = null
    private val context get() = _context!!

On a child Class whose parent already defines a public/protected method "getContext()".

I ran into the same situation and used @hotkey's suggestion but targeted to that specific use case, simply by annotating the getter itself only:

    @get:JvmName("getContext2")
    private val context get() = _context!!

This annotation ensures the automatic getter that is created has a different name than the parent one, without affecting your syntax/use of context.

Hope that helps!

Callas

Answer 9

1. Please change your context name because your parameter as context it will overruling with the base class parameter name which is also context by default. So changing the name of your parameter will help you.

   from: 
   var context: Context? = null
   
   to:
   var contextVideoFragment: Context? = null
   

Abstemious