How to disable inspections of compile error of IntelliJ IDEA - java

IntelliJ IDEA suggests there is compile error in source code of jetty.
In Eclipse, it does suggest nothing. And i can run this code. So i think this is the problem of IDEA.
My questions is how to disable this??

You can't just disable compile errors of source file in intellij. You can just disable inspection of some code patterns or compile warnings.
You can flag the folder not to be a source folder in module configuration, and the file will not be compiled anymore...
(But probably you need to investigate the underlined error to fix it really... maybe there is a conflict or a missing library in project configuration like the defined java Project Language Level)

Related

Using codenameone with lombok in Eclipse

I wonder if anyone is using codenameone with lombok in Eclipse. I've googled, but all I could find is an old question of mine.
A tiny success
I've tried it, took a demo project, modified nothing and opened it in my Eclipse configured for Lombok. When compiling, I got the same stacktrace as here. I've added
/usr/lib/jvm/java-8-oracle/lib/tools.jar
to the path under Preferences -> Installed JREs -> Edit -> JRE system libraries (which may be a pure non-sense) and it didn't help.
Then I've replaced compiler="modern" by compiler="extJavac" in build.xml and it compiles. I can even use Lombok annotations and they compile and work in the simulator.
The problem
I'm afraid, this was the simple part. I guess, for submitting, I need to replace the source code by the output of delombok. I've tried to submit it as is and nothing happened (no error, no response).
Has anyone done it already?
Any tips?
You shouldn't change the classpath but if the bytecode has access to the properties then it should "just work". If you look at the build.xml file you will notice that it has targets for every one of the supported platforms and before the target occurs you will see a compilation target that packages the JAR that's sent to the servers.
Steve wrote a post about porting other languages to Codename One. This is simple by comparison.
It actually works! All I had to do was to
add the path to lombok.jar to the Java Build Path1
in the javac call of the jar task
replace compiler="modern" by compiler="extJavac"
add the path to lombok.jar to the classpath
1 This is not recommended as the dependency is unavailable on the build server, but that's exactly right. Lombok is a compile-time only dependency and the build seems to be based on the dist.jar, where Lombok has already done its job.
One year later: There was a problem with my old setup, so I installed everything anew and it seems to work. Just note that there are three javac tasks in the build.xml.

Command works in terminal but not with java [duplicate]

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.

IntelliJ strange behavior

I've installed 30 day trial of IntelliJ 15.0.2 and cloned my project using git (I've created this project in community version). Project compiles (maven), runs, works. But new IntelliJ does not underline my errors, misspellings etc. When I wanted to commit, IntelliJ shows big number of errors, mostly on imports, as it can't resolve them. All dependencies are inside pom.xml. Once again, there were no errors in community version of IntelliJ. Ultimate version builds project just fine, but doesn't underline any errors and shows almost every import as unsolvable. What could go wrong? How to fix it?
Go to Build -> Make Project. After that errors should be visible in the project tree and in the specific project files.
You may need to mark the source dir, by right-clicking it on the project tab and select mark directory as -> source root
Check that you have a correct project sdk set in modules configuration. If IJ doesn't found any classes, jdk classes included, probably there is no sdk set.
You can also try to invalidate caches (in File menu) and rebuild project
I have faced with strange behaviour of Intelij Idea after update (syntax highlight stopped working). If you want to understand what is going on with yor Idea and can not quickly find an answer in internet, just go to Log files (for Mac OS the path is
~/Library/Logs/IntelliJIdea< your version>
List all files in that directory
ls -la
in terminal and find the latest one. Usually it should be idea.log (without numbers, logs with numbers identify logs for previous days). View that log. If that log contains a lot of ERRORS, try to find the reason (you can just type
grep "ERROR" idea.log
in terminal to find all lines that contain errors). Usually log files shouldn't contain errors, just info and warnings.
In my case syntax highlight stopped working. The log looked like
You can see here that error is in plugins that called like haxe.
I found that plugin in my idea, uninstalled it and idea started working properly. I investigated the log after and what I have seen there:
You can see just INFO in new rows.
Investigating a log can be really useful if you can not find the rootcase of your problem quickly in the internet. I hope it can help you even if it can be quite tricky.
Good luck!

IntelliJ IDEA can't compile with big size library

I have a library with huge amount of classes. This jar size = 276MB. When I include this jar to module dependencies, all seems fine. I can use import classes in editor. Navigate to classes and decompile them (Ctrl+N) and so on... All working fine.
But when I try compile this project, compiler tells me: "Can't find symbol class ....", "package ... does not exist".
Gradle compiles fine with this lib. Can JAR size provide problems like this?
To me It looks like IDE bug.
Try the following things:
Try File->Invalidate Caches
Try putting the the jar project correctly
Try recompiling the jar in the IDE (if you have the jav code) and relate to your main project.
If the above don't work, you need to report a bug.
Solved. This is not IDEA bug. This jar was a ZIP64 format... so, and java compiler bellow version 1.7_55 can't operate with it https://blogs.oracle.com/xuemingshen/entry/zip64_support_for_4g_zipfile. In my project i use 1.6 java, gradle use latest, so.
When i change project SDK problems is gone.

How to make javac squawk for incorrect package names in Java source files

Today, I ran into a java source file that had a typo in the 'package' statement at the top. The name of the package did not match the name of the directory the file was sitting in (one extra 's' at the end).
To my surprise, javac from 1.6, checkstyle, and pmd all passed the file as OK. The only tool that got around to complaining was javadoc, and only because it was the only file in the package, and a package with no classes in it is a fatal error to javadoc.
Is there some option to javac, or some other command-line tool (preferably with a maven plugin maven) that will squeal about this sort of goof?
I tested this with the latest version of Eclipse and it complains. Eclipse has Maven support.
Well, this seems like an interesting "feature". I fight with such errors regularly once a year. I would guess that PMD, FindBugs or a tool like that will find these errors. However if you say they do not, I can think of only three other options at the moment:
Use Eclipse compiler from Maven (to compile the sources and see the error). This should be possible although I have never tried it so far.
Create a custom PMD rule that will check the Java package name and compare it with the directory name.
Create your own Maven plug-in that will check it. This may not be very easy if you have not develop a Maven plug-in so far.
These are just ideas and should be treated as such.

Categories

Resources