Ran into another issue in my codebase. It took me ...

# announcements

[andreasmattsson]

Ran into another issue in my codebase. It took me a little while to track it down, but I suspect it might be a compiler error?

Seems data classes don't play well with overriding interface properties with @JvmField annotations:

interface Interface {
    val value: Int
}

data class Implementation(@JvmField override val value: Int) : Interface

class Test {
    @Test
    fun test() {
        assertEquals(Implementation(123), Implementation(123))
    }
}

It works if I do one of three things:
• don't override the interface variable
• remove the @JvmField annotation
• make it a normal (non-data class)
Dunno if this is intended to not be permitted, or a bug in the generated equals code. Either way if I leave it as is it compiles, but then throws an exception at runtime:

[andreasmattsson]

java.lang.AbstractMethodError: Implementation.getValue()I
	at Implementation.equals(Test.kt)
	at org.junit.Assert.isEquals(Assert.java:131)
	at org.junit.Assert.equalsRegardingNull(Assert.java:127)
	at org.junit.Assert.assertEquals(Assert.java:111)
	at kotlin.test.junit.JUnitAsserter.assertEquals(JUnitSupport.kt:32)
	at kotlin.test.AssertionsKt__AssertionsKt.assertEquals(Assertions.kt:57)
	at kotlin.test.AssertionsKt.assertEquals(Unknown Source)
	at kotlin.test.AssertionsKt__AssertionsKt.assertEquals$default(Assertions.kt:56)
	at kotlin.test.AssertionsKt.assertEquals$default(Unknown Source)
	at Test.test(Test.kt:13)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
	at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
	at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:412)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
	at java.lang.Thread.run(Thread.java:748)

[andreasmattsson]

(This is Kotlin 1.4.0 JVM BTW)

A couple questions I guess:
• Is this a known bug (I tried to search but couldn't find it)?
• If not, should I report it in the bug tracker?
• Is there a workaround that doesn't require me to abandon either @JvmField or the data class?

[ephemient]

https://youtrack.jetbrains.com/issue/KT-32753 not related to data class

[ephemient]

the interface as seen by Java is

public interface Interface {
    int getValue();
}

so overriding it with a @JvmField can't work. it should probably be rejected by the compiler instead of producing non-working output.

[andreasmattsson]

I suspected perhaps overriding with @JvmField wasn't supported. But it's not quite immediately obvious that it isn't/shouldn´t/can't be. I guess the fact that the compiler didn't immediately reject my code had me thinking that perhaps it would still create getters/setters as normal, but leave the backing field publicly visible from java as value.

[andreasmattsson]

@ephemient I took a closer look at the java decompiled generated bytecode:

public boolean equals(@Nullable Object var1) {
  if (this != var1) {
	 if (var1 instanceof Implementation) {
		Implementation var2 = (Implementation)var1;
		if (this.getValue() == var2.getValue()) {
		   return true;
		}
	 }

	 return false;
  } else {
	 return true;
  }
}

It never even tries to access the field through the interface, so not quite the same as KT-32753.
In fact, the case seems partially supported by data classes. E.g. the generated copy method does use field access rather than the method (which doesn't exist):

// $FF: synthetic method
public static Implementation copy$default(Implementation var0, int var1, int var2, Object var3) {
  if ((var2 & 1) != 0) {
	 var1 = var0.value;
  }

  return var0.copy(var1);
}

So I don't agree it's not related to data classes. Not quite the same issue, albeit the resolution to both might be the same (either generating accessors while exposing the field, or rejecting @JvmField on overridden properties).