I have seen variants of this question asked, but I have not seen an answer that was accepted. I am using IntelliJ IDEA to simply compile the TraversDemo sample plug in that Neo4J posted on GitHub. When I run mvn clean package I get no errors. But when I actually tried putting the .jar file into my plug ins folder on Neo4J Desktop . . . neo4j didn't recognize the plug in. So, I assumed something was wrong with my .jar file and I just tried to 'build' the java file in IntelliJ. When I did, I get this error:
Module 'TraversalPlugIn' production: java.lang.UnsupportedClassVersionError: org/neo4j/annotations/api/PublicApiAnnotationProcessor has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0
I have checked and rechecked my Java (for Windows 10) is Java 8. I checked the Java Configuration GUI and asked for updates. It said I had the most recent version. Does anyone have any idea how to solve this? I already tried screwing around with various options in Build,Execution,Deployment Java compiler. No combination seemed to work.
I finally fixed this. The solution was: (i) cut existing java code (and POM file); (ii) delete original project altogether; (iii) create a new maven project but choose JDK 16 as SDK this time; and (iv) paste Java code and POM xml into new project. Then I built it, and ran maven clean package, inserted the target snapshot into the plug ins folder and ... it finally worked.
Related
I'm trying to get an existing project working on a new platform (MacOS, M1) with Idea as the IDE. (I'm extremely new to Idea, but I'm getting help from other project developers.)
For a particular module in the project, any attempt to run pretty much any Grails command fails with an exception:
org.codehaus.groovy.runtime.memoize.EvictableCache.getAndPut(Ljava/lang/Object;Lorg/codehaus/groovy/runtime/memoize/MemoizeCache$ValueProvider;)Ljava/lang/Object
I have verified (to the extent I know how) that there's only one Groovy installation on the machine, and it's version 2.4.14 installed by sdkman. (Grails is 2.5.6.) Running the grails command as part of the Idea build (ie, from clicking "Build" or whatever inside the IDE) and running the grails command in the module top-level directory from the command line have exactly the same results.
I don't have much (well, any) experience with grails or groovy, but to me a "NoSuchMethodError" means that some piece of code was compiled against a different version of that class (EvictableCache) than the version that's actually in the jar file when grails runs. There are groovy .jar files in the project directory, but their presence seems to make no difference; it always gets that exception.
I'm using the Azul zulu8 JDK, downloaded from Azul directly. Formerly I had been using a version installed with brew but that made no difference.
Any ideas as to how to locate the .class file with the attempted call to getAndPut() in EvictableCache would be welcome.
edit — as I was looking at the stack traces from running a command, I noticed something. Again, my groovy is 2.4.14, as I can verify with groovy -version. At the top of one of my stack traces (maybe more than one) I see that the attempted call to getAndPut() is coming from a class called AbstractExtensionMethodCache. Well, as far as I can tell, that class did not become part of Groovy until version 3. So clearly something is messed up.
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.
I am having issues with IntelliJ - it shows me a "decompiled" version of the class instead of its source code if I ctrl+click the class.
This is what I see:
I am trying to open regular JDK source files.
The most relevant issue I found is explained here: Java sources replaced by decompiled files in Intellij
The most detailed answer I've found so far is there as well.
Yet it doesn't work for me:
Bytecode Viewer plugin is off.
Java Bytecode Decompiler plugin is off.
Platform, Project and Module all have same JDK version setup.
I have two JDKs available in IntelliJ: jdk1.8.0_161 and jbsdk8u112b287.2_windows_x86 (bundled with IntelliJ, but comes without src.zip). Tried with both (had to specify src.zip of jdk1.8.0_161 for jbsdk8u112b287.2_windows_x86) - no luck
src.zip is not corrupt - I can open it via WinRAR
When added jdk1.8.0_161 to IntelliJ, it automatically found src.zip. When manually adding src.zip to jbsdk8u112b287.2_windows_x86 Sourcepath tab - it started "Scanning for roots", but warned me that it "cannot determine what kind of files the chosen items contain" and offered me to "attach them as 'Sources'" so I agreed.
Tried File > Invalidate Caches / Restart... - same result.
Same issue in 2017.3 and fresh 2018.1 versions of IntelliJ.
Providing path for Documentation makes IntelliJ look for the documentation in the path specified. So it works as it should for both of JDKs. But not for sources.
Everything else works/compiles properly.
My settings:
1. Get the source files
Make sure you have downloaded and installed the source files of the JDK.
I'm on Arch Linux and installed them with pacman -S openjdk8-src which put a src.zip into /usr/lib/jvm/java-8-openjdk/. We'll use that zip file in the next step.
To list source packages of different JDK versions, do pacman -Ss "openjdk.*-src".
See this question on how to get the source files for your specific platform.
2. Point IntelliJ to the source files
In your module settings (open them with F4) under "Platform Settings" → "SDKs" → "Sourcepath", add the zip file containing the JDK source to your project JDK (be sure to pick the right JDK if IntelliJ lists more than one JDK) using the button with the plus sign:
3. Jump into the source
Select a JDK class, like Comparator, using IntelliJ's Search Everywhere or Ctrl+b with the cursor on the name of the class.
I also have the same problem. The problem for my case is that Project SDK is set to 13 [Invalid]. After I can Project SDK to a valid SDK. My problem is solved.
I tried all the things mentioned at other places for this but at the end I was doing a silly mistake. Intellij was pointing to JDK 11 for which there was no source code (I had both the SDKs 8 & 11). I removed JDK 11 and pointed to JDK 8. JDK had the source code, thus now I can see the source code on ctrl click. Also, I had disabled the bytecode viewer and decompiler plugins. Hope this helps some one.
This also happens for large files - IDEA decides to decompile them instead if indexing sources, which can take ages.
If you're willing to accept the drawdown, adding the following in Help | Edit Custom Properties might fix the problem:
idea.max.intellisense.filesize=4096
On ubuntu there was java version “OpenJDK” when I changed to “Oracle Java”, the error went away and javadoc returned
I meet same problem and finally it gone after I copy JDK to another folder and change config in IntelliJ. I think maybe cause there is a space in path before, because it is installed under "Program Files" folder.
For downloading the source code of class files belong to jar you can use download source option present on top right corner in the de-compiled class file.
On my Windows 10, expand maven:
For me going to File -> Project Structure -> Project -> SDK -> Add SDK -> Download JDK and selecting Oracle OpenJDK solved the problem. Prior to that I had a different JDK selected and apparently it didn't include source code
If you are in a maven project make sure in the project structure all the complied folders are in the excluded section.
I suggest to use Linux Instead of windows. It's easy to find and download Java.
If you are using Linux, you can download SDKMAN
Install Java by SDKMAN
# find version
$ sdk list java
# download
$ sdk install java x.y.z-amzn
ctrl+alt+shift+s add JDK
Switch project JDK
If you are using maven , Right click on Project explorer -> choose Maven -> chick on "reload projects"
This did the trick for me:
Make sure you select the option "Project Files" (instead e.g. "Project").
The Error:
Failed to sync Gradle project '-'
Error:Unable to find method 'org.gradle.internal.logging.progress.DefaultProgressLoggerFactory.(Lorg/gradle/internal/logging/progress/ProgressListener;Lorg/gradle/internal/time/TimeProvider;)V'.
You can see, a constructor inside a class, which is found in the logging jar (gradle_home/lib/grade-logging-version.jar) is missing.
So, I think the Class-Path does not contain this jar file.
Gradle Version: 3.5
Running using the Command Line works.
I have already tried this:
Gradle sync failed: Unable to find method
to-find-method, it does not work for me.
I have tried to use different versions.
I can't see any difference when enabling
"Use default gradle wrapper"
"Use gradle wrapper task configuration"
"Use local gradle distribution".
I had the exact same problem today.
The only way I was able to get it to work was to remove my IntelliJ IDEA IDE, get the latest from the website (with JDK) and put it in a new folder (i.e. no overwriting existing files).
After that, I deleted the .idea folder from the project and reimported it cleanly into the "new" IntelliJ.
I suspect upgrading IntelliJ from Version <= 2016.x caused the issue, since a new installation / clean extraction from archive caused it to work on the fly.
My IDEA 10.5.2 hilights all guava (10.0.1) classes with error (no class found). But code is compilling correctly. I have this trouble only with guava jar's. Other jar's warks correctly.
I try to change guava version and jdk version (1.6, 1.7) and idea version but there is no result.
What am i doing wrong?
IntelliJ's indexes must not be seeing the class files, even if javac is. Depending on how your project is set up, your build process may have a different classpath than IntelliJ's indexes. At least as likely, though, is simply the presence of some corrupt entry in IntelliJ's indexes. Either way, do the following:
From the "Project Structure" dialog (in the File menu), go to the Libraries screen and ensure that the guava jar or its parent folder is listed in one of your libraries
In the same dialog's Modules screen, ensure that the above library is listed in your module.
Exit the dialog and click File -> Invalidate Caches.
Restart IntelliJ. This might take awhile.
With the information given, I can't be sure this is your problem, but it's always the steps I go through when a library mysteriously stops working (which happens more often than I'd like...).
[Answering this old question as I came across this situation even in Idea Community Edition 2019.3.1]
For me it had been due to a change in the version of the library in the build.gradle file, and the solution was to recreate the project in a fresh folder
(or maybe I could've deleted some .idea or cache folders).
It mainly depends on the version of the library in the build.gradle file.
In my case, at first, the version of the library referred to was an earlier version and everything worked fine.
compile group: 'com.google.guava', name: 'guava', version: 'r05'
Later, had to use a newer version of the library and some classes in this new version.
compile group: 'com.google.guava', name: 'guava', version: '23.5-jre'
Since build.gradle was updated, the project built fine as a gradle task.
IntelliJ hadn't got updated - though usually it does after a change in the gradle file.
Even after trying to mess around with File->Project Structure, and File->Invalidate Cache and Restart, etc... it hadn't worked, and finally recreating the project seemed to be a good workaround.