IntelliJ Kotlin Classpath: Cannot access class

I'm importing a jar from another library and overriding one of the classes directly in my source code (please don't judge) by declaring it as same class name in same package and rely in classpath priority.

When doing so the code works fine (both with mvn and IntelliJ) and if the class I code into is java then even IntelliJ editor is happy. But if I code the class in kotlin I get:

Cannot access class 'com.****.raptor.gen.models.TextualEntry'. Check your module classpath for missing or conflicting dependencies

I wasn't able to reproduce it with any random library but only with our internal library.

The code I have is more or less this:

pom.xml:

    <dependency>
      <groupId>com.****.logistics.gpltconfig</groupId>
      <artifactId>entities-java</artifactId>
      <version>1.0.4-RELEASE</version>
    </dependency>

And this java code runs and shows in the editor fine:

    CustomsForm customsForm = new CustomsForm();
    customsForm.setDeclaredItemPrice(new TextualEntry<>());
    System.out.println("done java");

But this kotlin code runs fine but shows in the editor with an error:

    val customsForm = CustomsForm()
    customsForm.declaredItemPrice = TextualEntry<String>()
    println("done kotlin")

Any suggestion on how to do to get rid of the IntelliJ editor error in kotlin?

Like Tenfour04 - I want to know if you are intentionally shadowing the same package/class in your own code base. This is very risky since you are relying on some strategy for your implementation to win in the compiled code - I think the classpath loader searches in declared order, but mostly build/run tools don't give you options to declare ordering and once you go building something like a combined jar (see Maven Shade) then who knows.

But anyway, to answer your question...

I have seen something like this with a complex dependency graph. The problem for me is like this:

• project 1, module A, packaged as version p1a-1.0.1
• project 2, depending on p1a-1.0.1, packaged as version p2-2.0.0

then

• project 1 has moved all versions to p1xx-1.0.2, therefore
• project 1, module A, packaged as version p1a-1.0.2
• project 1, module B, depends on project 2 which depends on p2-2.0.0 that in turn depends on the older p1a-1.0.1

In this case the dependency manager (Maven in our case) ignores the deeper outdated dependency and all is well outside the editor/at run time. But IntelliJ doesn't like it an gives an editor-based error in some cases.

The editor error for us only seems to be around cases where there is "derived code" (in our case Lombok), and it's because IntelliJ is tracking the versions and thinks there is a conflict.

Seems like the version tracking cleverness is hitting you too. What about accepting 1 java class in your project as the "bridge" in this area... notwithstanding those warnings about "shadowing".

Pointcut

A different approach is consider using Aspect Orientated Programming to declare a pointcut where an AOP framework will wrap the class you want to change the behaviour of. See Spring's AOP implementation

I recommend coding the shadowing class in the same language it was originally written. If that's Java, just code it in Java. Your Kotlin compiler will pick it up and compile it along with Kotlin sources just fine.

This way, it's much easier to match the layout of the original class. In theory it's possible to do that correctly cross-language, but it's a hassle you can easily avoid.

It's a bug in IntelliJ.
IntelliJ team are working to solve it.

• https://youtrack.jetbrains.com/issue/IDEA-320386/IntelliJ-Kotlin-Classpath-Cannot-access-class?clearDraft=true&description=%0A%0AIU-231.8770.65,%20JRE%2017.0.6%2B10-b829.9x64%20JetBrains%20s.r.o.,%20OS%20Mac%20OS%20X(aarch64)%20v13.3.1,%20screens%203456.0x2234.0,%201920.0x1080.0

For the time being there is a workaround.
Put the following text as first line of that file (even before package)

@file:Suppress("MISSING_DEPENDENCY_CLASS", "MISSING_DEPENDENCY_SUPERCLASS")