I'm using IntelliJ 13.0.2 on OSX 10.9.5, using java 1.8. I get this error when trying to run a unit test inside IntelliJ. When I run compile or test via maven at the command line, it runs fine.
I've gone into File->Other Settings->Default Settings->Compiler->Annotation Processors and unchecked Enable annotation processing. I've also tried it with Enable annotation processing checked, and left the defaults selected.
We're running our tests with
#RunWith(MockitoJUnitRunner.class)
and the Annotation processor it can't find is org.mapstruct.ap.MappingProcessor. I don't know where it's getting that from, it's not in our imports. Maybe a dependency from Mockito?
This is happening because of realm. You can use these dependencies
classpath "io.realm:realm-gradle-plugin:2.0.0-SNAPSHOT
classpath 'com.android.tools.build:gradle:2.0.0-alpha3
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8
2.0.0 version of snapshots. Good Luck!
In the more general case that I encountered with my own Annotation Processor, here's what was necessary.
In the settings page, choose the "Processor Path" radio button. This has to be the target jar, you should try to locate that MappingProcessor jar.
I believe that this is because when running on the terminal, you would do:
javac -cp <pathToAnnotationProcessor.jar> <path to source.java>
Related
Intellij is giving me errors all around for brand new kotlin/spring project and I cannot build or run the project from the IDE.
If I do it from the command line however, there are no issues and I can build and run the app.
'classpath' in 'org.gradle.api.artifacts.dsl.DependencyHandler' cannot be applied to '(groovy.lang.GString)'
'apply' in 'org.gradle.api.plugins.PluginAware' cannot be applied to '(['plugin':java.lang.String])'
Cannot access class 'java.lang.String'. Check your module classpath for missing or conflicting dependencie
Type mismatch.
Required:
java.lang.String
Found:
kotlin.String
Any ideas to what may be the issue?
I tried Kotlin multiplatform JVM type mismatch in InteliJ but doesn't seem to fix the issue.
UPDATE:
Cleared gradle caches, reinstalled Intellij, Import project that was created from start.spring.io with Gradle and Kotlin selected.
Using default gradle wrapper and project jdk (the path says jre)? gives me an error. Open gradle settings just opens the file explorer.
Using default gradle wrapper and machine local JDK same issues with the dependencies from above.
This issue comes up if you set up your own module inside IntelliJ and you think that since you are doing a Kotlin (Maven) project, the SDK should be set to Kotlin. Wrong!
The problem is shown in the first image. The project SDK is set to Kotlin.
Change it to Java. Probably any 8+ Java will be good enough.
This solves the IDE errors and the compiler errors as well.
Unset KOTLIN_HOME and other Kotlin- or Java-related settings you may have in your environment (env to check, unset NAME to unset.)
Then kill any Gradle daemon still running (pkill -f GradleDaemon) and test your Gradle build from the terminal. If all goes well, remove the .idea directory; restart IDEA, making sure to run it without the stray environment variables (for example, launch idea.sh from the terminal where you unset them); and re-import your project, with the choice of using the default Gradle wrapper.
If you need to use standalone Kotlin versions, installed for example through SDKMAN, consider taking the SDKMAN activation lines out of your shell init file (.bashrc for Bash) and into a standalone script (say, ~/bin/sdkman) that will also change your shell prompt (PS1 in Bash) to remind you that you have entered a SDKMAN-managed CLI session.
As far as I understand, Lombok uses Java's Annotation Processors to generate additional methods.
With Maven 3.5 it works perfectly without adding any additional configuration, just add dependecy to Lombok and put some annotations like #Getter, #Setter.
However, if I open this project in IntelliJ IDEA 2018.2, all usages of generated getters/setters are highlighted as errors. I have Annotation Processing turned on, I tried to built project in IntelliJ or build in Maven and then use in IntelliJ, but it still requires Lombok Plugin to avoid false errors.
Is it some kind of bug? Error in workflow? Or maybe Lombok is using not only Annotation Processors, but some other stuff I didn't know and that's why IntelliJ + javac cannot figure out how to deal with it? It would be strange as javac itself compiles those files without errors
I know there are many questions "I have errors while using Lombok" and answers like "use the plugin". I'm not asking if I should use plugin, but why I should use it, why IntelliJ cannot handle it without plugin while javac does
IntelliJ's code analysis engine does not use javac or run annotation processors. Instead, IntelliJ uses its own Java parser and reference resolution logic, and builds its own code model. The Lombok plugin extends the code model to provide information about declarations generated by the Lombok annotation processor.
It's because IDEA syntax highlighter uses internal Java parser. If IDEA used just javac, then it wouldn't be able to highlight syntax errors as you type. It also gives much better hints about wrong code, so each Java construct, feature or annotation must be implemented by JetBrains team or there's plugin for it like in this case.
Annotation processing option is just for building project which is done via javac, but it's not for syntax highlighting.
Ale IDEs use lombok plugin be it intelij-idea or eclipse.
javac works fine with it - but remember that it works when for example you build you project with mvn clean package.
Then when you have your IDE - it works differntly - the code is not processed like in build task.
The plugin make it know to IDE what is this annotation and what code it generates underhood without need of javac.
What are the possible causes of a "java.lang.Error: Unresolved compilation problem"?
Additional information:
I have seen this after copying a set of updated JAR files from a build on top of the existing JARs and restarting the application. The JARs are built using a Maven build process.
I would expect to see LinkageErrors or ClassNotFound errors if interfaces changed. The above error hints at some lower level problem.
A clean rebuild and redeployment fixed the problem. Could this error indicate a corrupted JAR?
(rewritten 2015-07-28)
Summary: Eclipse had compiled some or all of the classes, and its compiler is more tolerant of errors.
Long explanation:
The default behavior of Eclipse when compiling code with errors in it, is to generate byte code throwing the exception you see, allowing the program to be run. This is possible as Eclipse uses its own built-in compiler, instead of javac from the JDK which Apache Maven uses, and which fails the compilation completely for errors. If you use Eclipse on a Maven project which you are also working with using the command line mvn command, this may happen.
The cure is to fix the errors and recompile, before running again.
The setting is marked with a red box in this screendump:
try to clean the eclipse project
you just try to clean maven by command
mvn clean
and after that following command
mvn eclipse:clean eclipse:eclipse
and rebuild your project....
Your compiled classes may need to be recompiled from the source with the new jars.
Try running "mvn clean" and then rebuild
The major part is correctly answered by Thorbjørn Ravn Andersen.
This answer tries to shed light on the remaining question: how could the class file with errors end up in the jar?
Each build (Maven & javac or Eclipse) signals in its specific way when it hits a compile error, and will refuse to create a Jar file from it (or at least prominently alert you). The most likely cause for silently getting class files with errors into a jar is by concurrent operation of Maven and Eclipse.
If you have Eclipse open while running a mvn build, you should disable Project > Build Automatically until mvn completes.
EDIT:
Let's try to split the riddle into three parts:
(1) What is the meaning of "java.lang.Error: Unresolved compilation
problem"
This has been explained by Thorbjørn Ravn Andersen. There is no doubt that Eclipse found an error at compile time.
(2) How can an eclipse-compiled class file end up in jar file created
by maven (assuming maven is not configured to used ecj for
compilation)?
This could happen either by invoking Maven with no or incomplete cleaning. Or, an automatic Eclipse build could react to changes in the filesystem (done by Maven) and re-compile a class, before Maven proceeds to collect class files into the jar (this is what I meant by "concurrent operation" in my original answer).
(3) How come there is a compile error, but mvn clean succeeds?
Again several possibilities: (a) compilers don't agree whether or not the source code is legal, or (b) Eclipse compiles with broken settings like incomplete classpath, wrong Java compliance etc. Either way a sequence of refresh and clean build in Eclipse should surface the problem.
I had this error when I used a launch configuration that had an invalid classpath. In my case, I had a project that initially used Maven and thus a launch configuration had a Maven classpath element in it. I had later changed the project to use Gradle and removed the Maven classpath from the project's classpath, but the launch configuration still used it. I got this error trying to run it. Cleaning and rebuilding the project did not resolve this error. Instead, edit the launch configuration, remove the project classpath element, then add the project back to the User Entries in the classpath.
I got this error multiple times and struggled to work out. Finally, I removed the run configuration and re-added the default entries. It worked beautifully.
Just try to include package name in eclipse in case if you forgot it
Import all packages before using it, EX: import java.util.Scanner before using Scanner class.
These improvements might work and it will not give Java: Unresolved compilation problem anymore.
Also make sure to check compiler compliance level and selected jdk version is same
As a weird case, I encountered such an exception where the exception message (unresolved compilation bla bla) was hardcoded inside of generated class' itself. Decompiling the class revealed this.
I had the same issue using the visual studio Code. The root cause was backup java file was left in the same directory.
Removed the backup java file
When the build failed, selected the Fix it, it cleaned up the cache and restarted the workSpace.
How do you debug java annotation processors using intellij?
Preferably using IDEA IntelliJ. I tried setting a breakpoint inside the processor and running but it did not break.
If you really need to debug an annotation processor, it might be better to run the annotation processor from the command line rather than within your IDE with debugging enabled and attach to that using your IDE's debugger.
If running javac directly, you can debug this by specifying the following extra parameters:
javac -J-Xdebug -J-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 ... (usual javac parameters go here)
If running Maven, use mvndebug instead of the standard mvn command - Maven runs the compiler in-process.
If running Ant, add the following to the ANT_OPTS environment variable before running:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
With all these executions, the javac, Ant or Maven process will wait for you to attach your debugger before it actually starts executing. IntelliJ instructions for this are here. For Eclipse, here.
This tutorial is written for an Android project. Main module name is "app" as usual. The project contains a submodule called "annotation" which is subdependency of "app". "app" module runs annotation processing with gradle declaration
apt project(':annotation') .
SIMPLE VERSION
(run compilation from terminal and attach from IDE)
[REQUIRED] Add a new project configuration "+" -> "Remote". Check "Single instance only". All other settings are generated automatically. Leave <whole project> as the classpath. Port should be left as the default 5005.
[REQUIRED] Make sure you stop all gradle instances by calling: ./gradlew --stop
[REQUIRED] Run the command : ./gradlew --no-daemon -Dorg.gradle.debug=true :app:clean :app:compileDebugJavaWithJavac
Run the APT project configuration in debug mode as fast as possible :)
[HINT] We start with an EMPTY gradle.properties file
[HINT] DO NOT USE gradle daemon ( --no-daemon / org.gradle.daemon=false option )
[HINT] Run gradle in debug mode ( org.gradle.debug=true option )
[HINT] Run app's module compilation not the processor's module compilation (app's compilation runs annotation processing!)
We DO NOT normally add any Java compiler settings in Android Studio (i.e. File -> other settings -> Default settings)
EXTENDED VERSION (use gradle.properties)
Add the following to your gradle.properties file:
org.gradle.daemon=false
org.gradle.debug=true
Run the compilation from terminal:
./gradlew :app:clean :app:compileDebugJavaWithJavac
ADVANCED VERSION (just press debug in IDE)
Add a bash script to your project main dir (e.g. compile.sh)
#!/bin/bash
./gradlew :app:clean :app:compileDebugJavaWithJavac &
Remember about the '&' sign for background processing.
Go to APT configuration settings we created in step 1 and add a Before launch configuration. Select Run external tool.
Add the path to the compile.sh script we created earlier.
Warning
Messing up gradle compilation, NullPointer exceptions during compilation etc. sometimes result in AndroidStudio being stuck (frozen on gradle refresh stage). If you cannot stop gradle from the IDE then use this command in the terminal:
ps -A | grep gradle | awk '{ print $1; }' | xargs kill -9
Turning off debug option during project refresh sometimes helps Android Studio to come back to the right track.
Follow these steps, These worked for me on android studio for gradle project:-
1).In gradle.properties add following lines
org.gradle.daemon=true
org.gradle.jvmargs=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
2).Edit Build COnfiguration and add Remote Configration
3).Run recently created run configuration APT.
4).Add break point in annotation processing code and build overall project
It is possible to run javac and debug it, as indicated higher. However in my case it was tedious to write the complete classpath, so I wanted to leave this to IDEA. So in the module where I wanted to apply my annotation processor, just create a class with main method.
public static void main(String[] args) {
com.sun.tools.javac.Main.main("-proc:only",
"-processor", "my.pkgs.MyAnnotationProcessor",
"my/pkgs/any/ClassIWantProcess.java");
}
For this to work you need to add $JAVA_HOME/lib/tools.jar to your SDK's JARs (by default it is not there). This is the same reason why appservers compiling JSPs need this JAR on their classpath - they need the compiler.
Then just set proper working directory for your run configuration (so the relative path to the java file is correct), set your break-point into the processor and debug at your will!
Benefit - classpath is set already by IDEA and used by the "inner" javac, because here it is not a separate process. I believe it's possible to translate it to other IDEs too.
For a Maven project, this post, which explains the following steps in a little more detail, worked for me:
Add "Remote" run configuration and set "port" to 8000.
Issue the command mvnDebug clean install from the project's directory (on the command line).
Run the run configuration. In order to start a new session after the processes quit, repeat from (2).
Remember to run mvn install on the project's dependencies when they change (e.g. if the annotation processor is in a different artifact than the project you are debugging it from).
I found the following resource that can help you: http://code.google.com/p/acris/wiki/AnnotationProcessing_DebuggingEclipse
The guy explains step-by-step how to debug annotation processors using Eclipse.
Annotation processing occurs during compilation, so normal debugging won't work. If you want to debug it in the context of you project, you can use IntelliJ remote debugging, while having Gradle or Maven in debug mode. Then you can put breakpoints in the Annotation Processor's files.
See Debugging an Annotation Processor in any project.
Disclaimer: I wrote the post.
Debugging an annotation processor with IntelliJ IDEA and Gradle
Set a custom VM option -Dcompiler.process.debug.port=5005: press Ctrl + Shift + A and select Edit Custom VM Options... in the list of actions to add a custom VM option then restart the IDE.
Create a remote debug configuration with default parameters: Run -> Edit Configurations... -> Add New Configuration (Alt + Insert) -> Remote.
Set breakpoints.
Build with Gradle from the terminal: $ ./gradlew --no-daemon -Dorg.gradle.debug=true clean build (it's okay if the execution of the command is frozen, don't terminate a process).
Debug the remote debug configuration within the IDE (see step 3): select a suitable remote debug configuration and press Shift + F9.
Hope it helps somebody :)
I was trying to create a Junit Testing framework within an existing RFT framework. The JUnit set up works fine to the point where we don't have to instantiate any framework classes.Whenever we are trying to access framework classes it throws the below exception. I did look for similar issues online but couldn't get a solution.Please suggest a solution if any body has faced a similar issue. RFT version is 8.1,JUnit version is 4
java.lang.NoClassDefFoundError: com.ibm.rational.test.lt.arm.IArmable
at java.lang.ClassLoader.defineClass(ClassLoader.java:265)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:521)
at java.net.URLClassLoader.access$300(URLClassLoader.java:66)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:985)
I figured it out:
You have to add the jar "com.ibm.rational.test.lt.rftarm_8.2.1.v20120105_1832.jar" to your Java Build Path. Mine was located in C:/Program Files/IBM/IMShared/plugins/. It came with RFT, but appears to not have been included in the Build Path by default.
This looks like a classpath error. If you are invoking JUnit from ANT, Maven, or some similar build tool then make sure you have the appropriate JAR files in the classpath. Remember, some JARS in turn have their own dependencies. Unless all those dependencies are in the classpath you will get the java.lang.NoClassDefFoundError.
If you are trying to run from the GUI client, it might be a little more difficult. Essentially, you will have to add all the dependencies to the jvm's -classpath option.