0

Questions

My questions are:

(Q) When running an app in the IntelliJ debugger, how does IntelliJ decide which bytecode to use ?

(Q) Does IntelliJ use whatever maven build plugin is being used or simulate it?

(Q) If multiple conflicting versions of code are being used (see mvn dependency:tree -Dverbose), how does IntelliJ decide which version of the code to use?

(Q) Where is the JAR file that IntelliJ creates so I could inspect it to see what versions of classes were used?

(Q) Is the process of selecting classes to use any different when running vs debugging?

Note: This question is being directed to IntelliJ's support staff as well as the SO community.

Background

I have an app that has been very problematic with IntelliJ with regards to picking the desired classes when running the application. 

The app is a Java Executable Jar that has been packaged with the maven-assembly-plugin.  It is not a SpringBoot application.

The problem stems from IntelliJ picking different class files than the maven-assembly-plugin which copies all of these classes (from all of the dependent jar files) into a single jar file. Naturally, only one version of a class can exist in the jar app (I believe the first class copied wins and the others are ignored).

IntelliJ (AFAIK) has no way of knowing what version of what class will be put into the JAR without knowing how the maven-assembly-plugin is implemented; So I'm looking for this answer.

Understanding the Question

To explain, see the example I created to understand how the maven-shade-plugin works. See Is there a sample project in github that shows how to use the maven-shade-plugin?. It's not a perfect fit for my problem/question, but it is in the public domain and it's close enough.

enter image description here

I'll frame my question based on the helloworld example. The helloworld.pom depends directly on loglib:2.0.0 so I would expect IntelliJ to select and use that version when compiling and running the application.  

The problem (code changes not being picked up)

The problem I ran into was when I changed the helloworld/pom.xml file to depend on loglib:2.1.0-SNAPSHOT and IntelliJ did not pick up the code changes and used a previous version of the dependency even though the source code was loaded inside of IntelliJ and the loglib/pom.xml file was changed to be version 2.1.0-SNAPSHOT.

The application is run by specifying the main class of the application com.steranka.play.HelloWorldApp. The Run/Debug configuration is:

Runtime Config

NOTE: I've done this exact thing many/many times and it's always worked, so I was puzzled. I also tried to reproduce the problem with a sample example and could not reproduce it. IntelliJ worked flawlessly picking up changes as it has always done in the past.

Trying to fix the problem (bytecode not matching source code)

I went through the list of things I've done in the past but after they were all completed, the problem remained.  The list of steps I followed included:

(1) Rebuilt the project (which included helloworld and loglib packages). Rebuild was done inside of IntelliJ. Nope.

(2) Verify that the correct maven dependency loglib:2.1.0-SNAPSHOT was being used in helloworld module, and that it shows up in the Maven Tools dependency list. 

(3) Clicked Reload all Maven Projects - run from Maven Tool. 

After IntelliJ restart, I made a change to a log.info() statement in the loglib:2.1.0-SNAPSHOT module ran my program and my changes to the log statement did not appear, only the previous version of the log message appeared.

This is the crux of the problem, and reason for my question.  Where is IntelliJ getting the bytecode that it is running? Is it from loglib/target/classes/* directory (this is my belief), or from maven .m2/repository/ ... / loglib:2.0.0-SNAPSHOT.

(3) I put a breakpoint on the log statement (that I changed) and ran the app in Debug mode and IntelliJ stopped on the log statement when I stepped over the statement the wrong log message was printed.  This is when I knew the bytecode IntelliJ was executing did not match the source code.

Detailed steps that reproduced the problem

To be clear I'll give timestamp versions because I don't know exactly what POM versions were being used:

  • T1: Starting with line that says: log.info("orig message");
  • T2: I changed the message to log.info("orig message - change1");
  • T3: IntelliJ did not pick up my change and log/console shows orig message
  • T4: I added some lines to the source code (multiple log statements)      log.info("this is strange")      log.info("why isn't this working")
  • T5: I put a breakpoint on the line why isn't this working and the breakpoint symbol appeared
  • T6: However, when I ran the program and IntelliJ stopped at the first breakpoint (orig message - change1) and when it stopped the 2nd breakpoint symbol was greyed out (indicating that the debugger could not stop on that line). 
  • T7: I stepped and IntelliJ was obviously running different code because the original message appeared instead of the changed message.

More Questions

(Q) When the IntelliJ debugger shows code that doesn't match what is being actually executed, how can I track down what code is actually being used? The answer to my previous questions should answer this.

The observable things I know to look at are:

  1. The Project Settings modules.
  2. The maven tool modules list and the dependencies.
  3. The External Libraries list in the Project Tool.
  4. The target/.jar and target/.classes files.
  5. Settings - java compiler used, maven used,

Common Reasons for this problem (bytecode not matching source code in debugger)

Reason 1: The most common reason for the above problem (in my past) has been making a code change in some module (say loglib when the loglib/pom.xml is at version 2.1.0-SNAPSHOT) and forgetting to update helloworld/pom.xml to refer to the -SNAPSHOT version. In my case I performed this check.

Reason 2: Years ago debuggers did not automatically compile code before the code was run, and this let to the problem whereby the bytecode being used matched the last time the file was compiled. The fix was/is simple, recompile the code and update the *.class file contains your code changes and the debugger code matches the bytecode that is being executed.

How to Reproduce the problem

The maven-shade-example (referred to above) can be used to reproduce the problem where the code shown in the debugger is not used at runtime.

git clone git@github.com:steranka/maven-shade-example.git
cd maven-shade-example
git checkout feature/fixing-problem-another-way
mvn clean install
java -jar helloworld\target\helloworld-1.0.0.jar

The output is:

Hello World!
What's up, Sam
Hello, Sam
Goodbye, Sam

But if you try to open this project inside IntelliJ and build and run it, you'll get an error. To run this, I right clicked on the hello word application and selected Run HelloWorldApp.main() (or Debug).

Hello World!
What's up, Sam
Exception in thread "main" java.lang.NoSuchMethodError: 'java.lang.String com.steranka.play.LogIt.sayHello(java.lang.String)'
    at com.steranka.play.GoodFeature.sayGoodbye(GoodFeature.java:6)
    at com.steranka.play.HelloWorldApp.main(HelloWorldApp.java:15)

What makes this un-nerving is the debugger jumps to the correct code if you click on the method, it just doesn't use that method at runtime.

The runtime configuration inside IntelliJ is: Runtime Config

PatS
  • 8,833
  • 12
  • 57
  • 100
  • 1
    How exactly do you run the app? If you run it using JAR Application configuration and use the Java Executable Jar you built with Maven, IDE will use exactly the classes in this jar file. If you run it using Application configuration, IDE will resolve the classpath from Maven project model and will use the output (target) directories for classes available from the project sources and .jar files from the local Maven repository for other dependencies. Maybe [this request](https://youtrack.jetbrains.com/issue/IDEA-266746) is related to your problem? – CrazyCoder Oct 28 '22 at 16:33
  • IntelliJ emulates maven. So you need to research how maven works. – Thorbjørn Ravn Andersen Oct 28 '22 at 18:11
  • 1
    If you want to check what classpath IntelliJ IDEA is using, see the first line in the Run console, it will list all the output paths and jars in order. – CrazyCoder Oct 28 '22 at 20:58
  • @PatS IntelliJ emulates Maven. There are some cornercases for speed but in general they behave the same. I would strongly recommend doing some Maven tutorials because understanding the lifecycle and all that will benefit you working with Maven. – Thorbjørn Ravn Andersen Oct 28 '22 at 23:12

1 Answers1

0

@CrazyCoder points out that IntelliJ will run the JAR file created using mvn clean install in the helloworld\target\helloworld-1.0.0.jar if you create a run configuration that says to use Java.

When I created a run configuration to use the Jar file, then IntelliJ's debugger properly executed the application and stepped into the correct files. That configuration looks like this:

IntelliJ Run/Debug Configuration

When I tried this solution on the actual code causing problems, it also worked. Strangely enough (to me) after switching to the JAR configuration and successfully running, I switched back to my Main class configuration and it also worked! So toggling between the two configurations might work for others as it did for me.

@CrazyCoder also points out that there is an outstanding bug/feature request with IntelliJ that asks for better support of the maven-shade-plugin. See https://youtrack.jetbrains.com/issue/IDEA-266746

@Thorbjørn Ravn Andersen states that IntelliJ emulates Maven so in general the behavior between building and running inside IntelliJ should match what happens with Maven.

PatS
  • 8,833
  • 12
  • 57
  • 100