I've tagged a method in my code with javax.annotation.CheckForNull and use it, without checking for null, in another place. When I run this code through FindBugs in Eclipse (via the plugin), there is no warning though.
Assuming there should be a warning (if not, what's a good test case?), why is it not showing?
It does show other warnings, not related to annotations.
I think the answer you're looking for can be found in here: Findbugs using jsr305 annotations in eclipse is not finding bugs
(try running findbugs outside of eclipse)
I just tested (Windows, Eclipse Helios, latest plugin) and it worked, warning of possible dereferencing of a null variable.
Perhaps check if this warning is not deactivated in your settings.
[EDIT] Tested with both javax.annotation.CheckForNull and edu.umd.cs.findbugs.annotations.CheckForNull, and both in the same class and in a class in a different package.
Related
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.
I am developing a Java application and Using SonarLint to test the code quality.
Sonar shows the error : Take the required action to fix the issue indicated by this comment.
For below line of code:
// FIXME: temp here until we drop tomee or remove all exceptions from ejb <-> non-ejb path.
Is there any way I can suppress the warning in SonarLint ?
You can use the connected mode to bind your project in the IDE to a project in SonarQube. SonarLint will use the same code analyzers and rules as the ones in SonarQube.
In SonarQube, it's possible to change the quality profile assigned to projects and in this way, to enable or disable rules.
More information: https://www.sonarlint.org/intellij/howto.html
I checked several places and tried many things to suppress the warnings, but turns out that //FIXME are considered as major warnings in Sonar . You need to take care of them by removing the tag and fixing the issue which was mentioned in the tag (by the developer of tag).
Or you can simply remove the tag if that issue is not needed to be fixed or that is itself not an issue now.
I want to use the SonarLint plugin for Eclipse. I installed it, but it doesn't seem to be catching everything it should. After installing it, I tried to write code that should trigger SonarLint issues. For example, the picture on the site http://www.sonarlint.org/eclipse/ , indicates that SonarLint should complain when I use == to compare floats because "Equality Tests should not be made with floating point numbers". However, on my side, I do not get this message. Normally I would think that SonarLint wasn't installed correctly, but it does complain about the class, saying to "Add some tests to this class." so it seems to exist. This is the only message the SonarLint gives me.
Here is a picture of what my Eclipse looks like. I have included multiple issues that should trigger a SonarLint message but almost all of them do not. Is there some setting or issue that needs to be changed that I haven't set yet?
Picture of my Eclipse
I have Eclipse Neon running Java 8 and I installed SonarLint version 2.2. I am planning on using SonarLint in the "Standalone" mode rather than the "Connected" mode which I believe means that I do not need to set up anything after installing the plugin on Eclipse.
Thanks in advance for your help
Figured it out. For some reason, because I named my Java Project "Test", I think it assumed that the project was filled with Unit Tests based on JUnit class naming conventions. When I made a project with a different name, SonarLint worked as expected.
I see from the javadoc that the #SuppressWarnings annotation applies to
TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE
targets. Why does it not also apply to PACKAGE?
I have some generated code which contains some raw types warnings. I'd like to be able to add a package-info.java file for the generated classes (in a separate physical directory but the same java package) which tells eclipse to ignore any raw types warnings emanating from the generated classes in package.
Why is this not supported? Is there an alternate way of suppressing a warning in an entire package?
The reason that suppressing warnings at the package level is not allowed was explained in the response to an old bug report (Status - Closed, Will Not Fix): Allow SuppressWarnings to be specified at the package level.
The warnings actually indicates potential problems in the
generated code.
Currently, SuppressWarnings have the desirable property of
only affecting lexically nested code. This means that you
can immediately see if a warning might be suppressed in
code you're reading.
This proposal would violate this property to solve an uncommon
problem which in most cases can be worked around.
There are a couple of work arounds suggested in that response as well.
compile the generated code by itself using -source 1.4 and -target 5.
request an updated version of javacc which either uses suppresswarnings
or doesn't generate code which causes warnings.
I think the first suggestion, putting the generated code in its own project, should work for you. The second suggestion looks like its more specific to the problem in the bug report. I don't know if you're using javacc or not.
Good question. Probably this will be fixed by Oracle in future.
But now I can suggest you the following. Put all generated code to separate project. BTW it is common practice. Then configure this project to be patient to warnings. For example in eclipse you can open project properties/Java Compiler/ Errors/Warings, select "enable project specific settings" and disable all warnings.
Some of my colleagues lack discipline and not always write documentation of their classes(not always = never). I was trying to force them to write documentation by setting project warnings for missing comment javadocs. We got two source folders 'src' and 'tests' - obviously not all #Test methods needs documentation and this warning there is redundant. But now all undocumented tests got these annoying warnings, the project got hundreds of warnings and I'm afraid that some real dangerous warnings will be missed(because there are hundreds of useless ones).
How to set warnings only on the 'src' folder, and ignore the warnings on 'tests' folder?
I'm afraid there is no setting to disable missing javadoc validation strictly for Test classes/methods. There even was a suggestion posted on Eclipse bugzilla here but eventually it came to an dead end.
The only, nonelegant way of solving this issue is by annotating those test methods with #SuppressWarnings("javadoc") annotation.