# compilation error Published articles for compilation error. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Leveraging @RequireOptIn to create composables that can be used only in previews DevFeed: [Leveraging @RequireOptIn to create composables that can be used only in previews]() Original publisher: [Read original article]() Author: Leonidas Partsas Published: 2026-03-22T14:32:15Z Content type: tutorial Language: en Sources: [le0nidas]() Topics: [Kotlin](), [Jetpack Compose](), [Code]() Tags: [android](), [compilation-error](), [components](), [how-to](), [jetpack-compose](), [know-your-tools](), [kotlin](), [module](), [preview](), [production](), [requireoptin]() ### AI overview This tutorial explains how to use Kotlin's @RequiresOptIn mechanism with a @PreviewOnly annotation to expose composables for preview rendering across modules while preventing their use in production code. Explicit opt-in is required at each call site, otherwise compilation fails. ### Source excerpt Anyone working with Kotlin, especially in the android world, has dealt with RequireOptIn. Actually they had to deal with the consequence of its application which is to explicitly opt-in into using a piece of code that is annotated with it. @RequiresOptIn In a nutshell, if you want the consumer of your code to be fully ... Continue reading Leveraging @RequireOptIn to create composables that can be used only in previews -> ## Cannot resolve symbol 'VERSION\_3\_17' in jOOQ generated code DevFeed: [Cannot resolve symbol 'VERSION\_3\_17' in jOOQ generated code]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-08-30T06:56:20Z Content type: tutorial Language: en Sources: [jOOQ]() Topics: [Code](), [Compiler](), [Code generation](), [Gradle](), [Maven]() Tags: [code-generation](), [compilation](), [compilation-error](), [compiler](), [errors](), [gradle](), [java](), [jooq](), [jooq-in-use](), [location](), [maven]() ### AI overview This article explains that a VERSION_3_17 compilation error in jOOQ-generated code is caused by a mismatch between the runtime library and code generation library. The runtime version must be at least as new as the code generation version; matching both versions is recommended. ### Source excerpt Starting with jOOQ 3.16 and #12601, there may be a compilation error with a message like this in your jOOQ generated code: [ERROR] .../DefaultCatalog.java:[53,73] cannot find symbol[ERROR] symbol: variable VERSION_3_17[ERROR] location: class org.jooq.Constants Typically, this error is mixed with other compilation errors in generated code. Its purpose is to help troubleshoot these other compilation errors. ... Continue reading Cannot resolve symbol 'VERSION_3_17' in jOOQ generated code -> ## All About Opt-In Annotations DevFeed: [All About Opt-In Annotations]() Original publisher: [Read original article]() Author: Márton Braun Published: 2021-09-28T15:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Kotlin](), [Library]() Tags: [android](), [article](), [code](), [compilation](), [compilation-error](), [guide](), [how-to](), [kotlin](), [marton-braun](), [visibility](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview A guide to Kotlin opt-in annotations, explaining how to create opt-in marker annotations, mark APIs as requiring opt-in, and use those APIs correctly. It also discusses severity levels, compilation behavior, and applications in libraries and multi-module projects. ### Source excerpt Have you ever encountered APIs that show warnings or errors when you use them, saying that they're internal or experimental? In this guide, you'll learn everything you need to know about opt-in APIs in Kotlin: how to create and use them, and all their nuances. ## Using @JvmSuppressWildcards to resolve Kotlin and Java generic type issues DevFeed: [Using @JvmSuppressWildcards to resolve Kotlin and Java generic type issues]() Original publisher: [Read original article]() Author: Chao Zhang Published: 2021-02-23T16:01:15Z Content type: tutorial Language: en Sources: [Stories by Chao Zhang on Medium]() Topics: [Kotlin](), [generics](), [Java](), [Android](), [Dagger](), [recyclerview]() Tags: [android](), [android-app-development](), [compilation-error](), [compiler](), [dagger](), [generics](), [java](), [kotlin](), [kotlin-generics](), [recyclerview]() ### AI overview This tutorial explains how Kotlin generics interact with Java in mixed Kotlin-Java codebases, including Android applications and Dagger-based dependencies. It shows how the @JvmSuppressWildcards annotation can resolve compilation and type-inference problems when Kotlin generic APIs are consumed by Java code. ### Source excerpt Photo: amirali mirhashemian from Unsplash If generic types are exposed in Kotlin API, consider @JvmSuppressWildcards so that your Java consumer can compile successfully. Kotlin generics are different from (in my opinion, smarter than) Java generics. Kotlin generics has declaration-site variance and type projections, which are officially documented here. Generics is a gigantic topic itself. My usual practice is to leverage IDE warnings and compiler error messages to fix my code since they usually contain the necessary information to show you where you did wrong. However, as we are Kotlinizing our codebase from Java to Kotlin, it is possible to have a sandwich-style code dependency that mixes Java code and Kotlin code. In such cases, when dealing with generics, your compiler and IDE may not be smart enough to help you fix those issues. What is sandwich-style code dependency?🥪 Sandwich-style Kotlin conversion At a certain time during your Java to Kotlin conversion, there could be some Java code depending on Kotlin code, which in turn depends on Java code. A typical example on Android is that your app code in Java depending on your library in Kotlin, which depends on Android SDK in Java. Even if your app code is written purely in Kotlin, the sandwich might still exist: The Java-based annotation processing Dagger, depends on your app code in Kotlin, which depends on Android SDK in Java. Now let's look at how the secret sauce @JvmSuppressWildcards can help us by making our generic sandwich tasty. Sandwich: List in RecyclerView methodshttps://medium.com/media/87fd0c63db2b9c82af2b241bf61cef31/href With the code above, the following compilation error is observed: MyChildAdapter.java:13: error: name clash: onBindViewHolder(MyViewHolder,int,List) in MyChildAdapter overrides a method whose erasure is the same as another method, yet neither overrides the other The error message leads us to think that we need to change our type here: Change the Kotlin generic para