Possible Link to Known Kotlin Reflection Bug

Oct 13, 2025 by recoveryshake.com 124 views

Introduction

We are grateful for the hard work that has gone into creating this library, which has been working well for us overall. However, we have encountered an issue that occurs when using the structure-capturing operator (@) to log the contents of a LinkedHashSet. The following exception is thrown:

java.lang.IllegalStateException: Cannot infer visibility for inherited open fun clone(): kotlin.Any defined in java.util.LinkedHashSet[JavaMethodDescriptor@5bf15029],
	at kotlin.reflect.jvm.internal.impl.descriptors.runtime.components.RuntimeErrorReporter.reportCannotInferVisibility(RuntimeErrorReporter.kt:31),
	at kotlin.reflect.jvm.internal.impl.load.java.components.DescriptorResolverUtils$1$1.invoke(DescriptorResolverUtils.java:79),
	at kotlin.reflect.jvm.internal.impl.load.java.components.DescriptorResolverUtils$1$1.invoke(DescriptorResolverUtils.java:76),
	at kotlin.reflect.jvm.internal.impl.resolve.OverridingUtil.resolveUnknownVisibilityForMember(OverridingUtil.java:909),
	at kotlin.reflect.jvm.internal.impl.load.java.components.DescriptorResolverUtils$1.addFakeOverride(DescriptorResolverUtils.java:76),
	at kotlin.reflect.jvm.internal.impl.resolve.OverridingUtil.createAndBindFakeOverride(OverridingUtil.java:737),
	at kotlin.reflect.jvm.internal.impl.resolve.OverridingUtil.createAndBindFakeOverrides(OverridingUtil.java:579),
	at kotlin.reflect.jvm.internal.impl.resolve.OverridingUtil.generateOverridesInFunctionGroup(OverridingUtil.java:500),
	at kotlin.reflect.jvm.internal.impl.load.java.components.DescriptorResolverUtils.resolveOverrides(DescriptorResolverUtils.java:70),
	at kotlin.reflect.jvm.internal.impl.load.java.components.DescriptorResolverUtils.resolveOverridesForNonStaticMembers(DescriptorResolverUtils.java:46),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.addFunctionFromSupertypes(LazyJavaClassMemberScope.kt:366),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.computeNonDeclaredFunctions(LazyJavaClassMemberScope.kt:325),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.functions$lambda$4(LazyJavaScope.kt:123),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.accessor$LazyJavaScope$lambda4(LazyJavaScope.kt),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope$$Lambda$4.invoke(Unknown Source),
	at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$MapBasedMemoizedFunction.invoke(LockBasedStorageManager.java:578),
	at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$MapBasedMemoizedFunctionToNotNull.invoke(LockBasedStorageManager.java:681),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.getContributedFunctions(LazyJavaScope.kt:273),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.getContributedFunctions(LazyJavaClassMemberScope.kt:865),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.computeDescriptors(LazyJavaScope.kt:378),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.allDescriptors$lambda$0(LazyJavaScope.kt:64),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.accessor$LazyJavaScope$lambda0(LazyJavaScope.kt),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope$$Lambda$0.invoke(Unknown Source),
	at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408),
	at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527),
	at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.getContributedDescriptors(LazyJavaScope.kt:357),
	at kotlin.reflect.jvm.internal.impl.resolve.scopes.ResolutionScope$DefaultImpls.getContributedDescriptors$default(ResolutionScope.kt:50),
	at kotlin.reflect.jvm.internal.KDeclarationContainerImpl.getMembers(KDeclarationContainerImpl.kt:58),
	at kotlin.reflect.jvm.internal.KClassImpl$Data.declaredNonStaticMembers_delegate$lambda$22(KClassImpl.kt:173),
	at kotlin.reflect.jvm.internal.KClassImpl$Data.accessor$KClassImpl$Data$lambda10(KClassImpl.kt),
	at kotlin.reflect.jvm.internal.KClassImpl$Data$$Lambda$10.invoke(Unknown Source),
	at kotlin.reflect.jvm.internal.ReflectProperties$LazySoftVal.invoke(ReflectProperties.java:70),
	at kotlin.reflect.jvm.internal.ReflectProperties$Val.getValue(ReflectProperties.java:32),
	at kotlin.reflect.jvm.internal.KClassImpl$Data.getDeclaredNonStaticMembers(KClassImpl.kt:173),
	at kotlin.reflect.jvm.internal.KClassImpl$Data.allNonStaticMembers_delegate$lambda$26(KClassImpl.kt:182),
	at kotlin.reflect.jvm.internal.KClassImpl$Data.accessor$KClassImpl$Data$lambda14(KClassImpl.kt),
	at kotlin.reflect.jvm.internal.KClassImpl$Data$$Lambda$14.invoke(Unknown Source),
	at kotlin.reflect.jvm.internal.ReflectProperties$LazySoftVal.invoke(ReflectProperties.java:70),
	at kotlin.reflect.jvm.internal.ReflectProperties$Val.getValue(ReflectProperties.java:32),
	at kotlin.reflect.jvm.internal.KClassImpl$Data.getAllNonStaticMembers(KClassImpl.kt:182),
	at kotlin.reflect.full.KClasses.getMemberProperties(KClasses.kt:148),
	at io.klogging.rendering.Destructuring_jvmKt.destructure(Destructuring.jvm.kt:29),
	at io.klogging.rendering.DestructuringKt.getDestructured(Destructuring.kt:29),
	at io.klogging.rendering.RenderEcsDotNetKt.RENDER_ECS_DOTNET$lambda$3(RenderEcsDotNet.kt:54),
	at io.klogging.sending.EventSenderKt$senderFrom$1$1.invoke(EventSender.kt:23),
	at io.klogging.sending.EventSenderKt$senderFrom$1$1.invoke(EventSender.kt:23),
	at kotlin.text.StringsKt__AppendableKt.appendElement(Appendable.kt:84),
	at kotlin.collections.CollectionsKt___CollectionsKt.joinTo(_Collections.kt:3493),
	at kotlin.collections.CollectionsKt___CollectionsKt.joinToString(_Collections.kt:3510),
	at kotlin.collections.CollectionsKt___CollectionsKt.joinToString$default(_Collections.kt:3509),
	at io.klogging.sending.EventSenderKt.senderFrom$lambda$0(EventSender.kt:23),
	at io.klogging.internal.Sink.sendDirect$klogging(Sink.kt:101),
	at io.klogging.internal.Dispatcher.sendDirect$klogging(Dispatcher.kt:61),
	at io.klogging.internal.Emitter.emitDirect(Emitter.kt:76),
	at io.klogging.impl.NoCoLoggerImpl.emitEvent(NoCoLoggerImpl.kt:72),
	at io.klogging.NoCoLogger$DefaultImpls.emitEvent$default(NoCoLogger.kt:44),
	at io.klogging.NoCoLogger$DefaultImpls.log(NoCoLogger.kt:72),
	at io.klogging.impl.NoCoLoggerImpl.log(NoCoLoggerImpl.kt:41),
	at io.klogging.NoCoLogger$DefaultImpls.info(NoCoLogger.kt:105)

Reproduction

The issue only occurs when the code runs inside a Jetty-based web service. We have tried the following Jetty versions:

9.4 (with JRE 11)
9.4 (with JDK 11)
11 (with JDK 21)

Outside of Jetty (e.g., a standalone console application in the same Docker container), everything works as expected.

Possible Causes

From a quick look at the library's internals, we noticed two points that might be relevant:

Destructuring logic: In Destructuring.jvm.kt, the code loops through all the members of the object being "destructured" and sets property.isAccessible = true. This effectively makes private members visible and they will be logged. It's possible that this code line triggers the reflection issue, since the exception mentions visibility ("Cannot infer visibility").
Exception handling: If an exception occurs in this part of the code, it bubbles up without being caught. This led to our logging call actually stopping subsequent code from running. It might be worth considering an internal try-catch, so that logging failures do not disrupt normal application flow.

Possible Link to Known Kotlin Reflection Bug

We have found several Kotlin issue tracker entries referencing "Cannot infer visibility..." errors on Java classes with clone() methods, some dating as far back as Kotlin 1.1. Examples include:

It appears to be a tricky area in Kotlin reflection, but since we only see it in a Jetty context, we suspect a combination of factors (classloader differences, security constraints, or reflection quirks) that trigger this Kotlin bug.

Conclusion

We appreciate any guidance you can provide in resolving this issue. If we can help test a fix

Q: What is the issue with destructuring in LinkedHashSet?

A: The issue is that when using the structure-capturing operator (@) to log the contents of a LinkedHashSet, an exception is thrown with the message "Cannot infer visibility for inherited open fun clone(): kotlin.Any defined in java.util.LinkedHashSet".

Q: What are the possible causes of this issue?

A: From a quick look at the library's internals, we noticed two points that might be relevant:

Destructuring logic: In Destructuring.jvm.kt, the code loops through all the members of the object being "destructured" and sets property.isAccessible = true. This effectively makes private members visible and they will be logged. It's possible that this code line triggers the reflection issue, since the exception mentions visibility ("Cannot infer visibility").
Exception handling: If an exception occurs in this part of the code, it bubbles up without being caught. This led to our logging call actually stopping subsequent code from running. It might be worth considering an internal try-catch, so that logging failures do not disrupt normal application flow.

Q: Is this issue related to a known Kotlin reflection bug?

A: Yes, we have found several Kotlin issue tracker entries referencing "Cannot infer visibility..." errors on Java classes with clone() methods, some dating as far back as Kotlin 1.1. Examples include:

Q: Why does this issue only occur in a Jetty-based web service?

A: We suspect that a combination of factors (classloader differences, security constraints, or reflection quirks) that trigger this Kotlin bug are specific to the Jetty environment.

Q: How can we help resolve this issue?

A: We would be happy to help test a fix or workaround. If you have any suggestions or ideas, please let us know.

Q: What can be done to prevent logging failures from disrupting normal application flow?

A: Considering an internal try-catch in the logging code could help prevent logging failures from stopping subsequent code from running.

Q: Are there any other possible solutions to this issue?

A: We are open to any suggestions or ideas that might help resolve this issue. If you have any other possible solutions, please let us know.

Q: How can we get in touch with the library developers to report this issue?

A: You can reach out to the library developers through their official channels, such as their website or social media. We appreciate any guidance they can provide in resolving this issue.