Environment: IntelliJ IDEA Ultimate 2022.2 Build 222.3345.118
I have overridden the method with #Deprecated annotation.
I want to suppress deprecated API usage on certain methods. But the Option+Enter action has only useless suggestions.
We tried to suppress it by means of SupressWornings and //noinspection ScalaDeprecation. I would like to disable Inspection as a last resort because there are some warnings that I want to suppress and others that I do not want to.
In Scala you can use the #nowarn annotation to this end. You can see a very nice rundown of how to use both this annotation locally or other options on the overall project on this blog post by Lukas Rytz.
In your case, I believe you can use the following annotation:
#nowarn("cat=deprecation&origin=your\.package\.YourDeprecatedClass")
You can see an example of how I used this on this commit.
As you can see, the annotation can be applied even to individual expression via type ascription, but you can also apply it to methods. In general, I like to keep my #nowarns as specific and fine-scoped as possible. You can also tell the compiler to warn you when a #nowarn is not doing anything, so that you don't have to keep unused annotations around the code.
If you have deprecated APIs that you need to use (e.g. even though they are deprecated, you still need to test them) and the usages are all over the place, you might want to evaluate the option of configuring the warning suppression as a compiler option with something like
-Wconf:cat=deprecation&origin=your\.package\.YourDeprecatedClass
passed to the compiler. Here is an example of this as well (we use Bazel instead of SBT but I'm fairly sure that setting up SBT for this is quite simple).
For any other information, the blog post I linked above is an excellent source.
Related
I've been using IntelliJ IDEA as a Java IDE for a decade, and I created my favorite syntax highlight scheme back in 2009. It remains unmodified since around 2015 just because I find it very comfortable to me making reading code easier and faster. However, there are some syntax elements that are not easy to read under certain circumstances. The most important elements among those, I guess, are Java annotations that appear messy and are just hard to read if there are too many annotations. I prefer the following annotations order scheme:
(possibly disabled) "entry points": #Disabled, #Test, #RequestMapping, #Scheduled, etc;
Java core: #Override, #FunctionalInterface, #Target, #RetentionPolicy, etc;
contracts: JSR-305 (#Nonnull, #Immutable), Checker Framework;
codegen: Lombok #Getter, #EqualsAndHashCode, etc;
runtime: various custom #Foo's and #Bar's, #Entity, #OneToMany, #JsonProperty etc;
documentation: #Api***, etc;
#SuppressWarnings as the least significant one.
Sometimes I place them in wrong order and it makes reading code less convenient making me feel that the code style is not as strict as I want it to be. My question is: it possible to define an order for annotations (or their groups) so I could reorder? IntelliJ IDEA can do exactly the same for imports.
(Also, is it possible to highlight such groups with different colors?)
There is a feature request to support such behaviour, please upvote the feature.
I want to do something like this:
#Testing
private void methodThatGivesWarningIfUserTriesToUseThis() {
}
where #Testing is a custom annotation/decorator in Java. I'd like the behaviour of this #Testing annotation to act ALMOST EXACTLY like the #Deprecated annotation - if i or someone else accidentally tries to use this in other parts of the code, the IDE will give a warning (and the method name also has a strike-through across the font). So for ex
how do i do this?
**note: i do not want to use #Deprecated because the method is not deprecated, i just want only to use it for testing purposes
**this marker should also be checked at compile time, not runTime.
The problem is that annotations are, as their name states, only for annotating :)
Creating such annotation is pretty easy, you need to do something like this:
public #interface Testing
In order for it to be used by your IDE at compile time you have to write a plug-in.
Here is a good start I found in another SO question for starting with the plugin development.
It sounds like you're describing something like #VisibleForTesting, which is part of the Guava libraries (formerly known as "Google Collections"). If you do create one of your own, you'll probably want it to be #Documented and #Retention(SOURCE).
I'm not aware of any hook or feature that would cause non-#Deprecated members to trigger warnings or IDE flags as if they were #Deprecated. Because the Mirror API and Reflection API don't track individual expressions and statements (as documented in this SO answer), you probably won't have much luck detecting it yourself without a full Java parser.
You might consider writing a custom Lint rule to solve this problem. When your #Testing annotation is detected, the IDE would show a Lint warning (e.g., a yellow underline in the case of Eclipse+ADT).
A detailed guide to scanning Java source files for specific issues with Lint can be found in the Android Tools docs here.
So like probably many people out there I usually comment out code temporarily, mostly for debugging purposes. I currently put something like **DEBUG** or whatever that is easily searched for, but I thought having the compiler output a warning (or even an error) whenever it finds code that is temporarily commented out could be useful. I thought of using an annotation, but annotations can't be used to mark comments.
Does anyone know of a better approach than putting an easily searchable string in the commented-out section of code?
there are plenty of code inspection tools out there that can alert you to the presence of code patterns that you define. most of them have built-in support for detecting common stuff like "//todo" comments left in code etc.
most IDEs support auto-detection of //todo as well (intellij idea, for example).
a common command-line tool for this is checkstyle. you could run it as part of your build and have it point these things out to you
At least Eclipse allows you to use (and define your own) markers put in comments, that can be easily listed afterwards. There's at least TODO and XXX, but I believe you could make your own as well.
If you're using Maven, consider to use the taglist-maven-plugin.
I need to diagnose all invoked methods in a class(either declared in the class or not) using it's source code. Means that give the class source code to a method as an input and get the invoked method by the class as the output. In fact I need a class/method which operates same as java lexical analyzer .
Is there any method to diagnose all invoked methods ?
of course I tried to use Runtime.traceMethodCalls(); to solve the problem but there was no output. I've read I need to run java debug with java -g but unfortunately when I try to run java -g it makes error. Now what should I do ? Is there any approach ?
1) In the general case, no. Reflection will always allow the code to make method calls that you won't be able to analyze without actually running the code.
2) Tracing the method calls won't give you the full picture either, since a method is not in any way guaranteed (or even likely) to make all the calls it can every time you call it.
Your best bet is some kind of "best effort" code analysis. You may want to try enlisting the compiler's help with that. For example, compile the code and analyze the generated class file for all emitted external symbols. It won't guarantee catching every call (see #1), but it will get you close in most cases.
You can utilize one of the open source static analyzers for Java as a starting point. Checkstyle allows you to build your own modules. Soot has a pretty flexible API and a good example of call analysis. FindBugs might also allow you too write a custom module. AFAIK all three are embeddable in the form of a JAR, so you can incorporate whatever you come up with into your own custom program.
From your question it is hard to determine what is exactly problem you're trying to solve.
But in case:
If you want to analyze source code, to see which parts of it are redundant and may be removed, then you could use some IDE (Eclipse, IntelliJ IDEA Community Edition etc.) In IDE's you have features to search for usages of method and also you have functionality to analyze code and highlight unused methods as warnings/errors.
If you want to see where during runtime some method is called, then you could use profiling tool to collect information on those method invocations. Depending on tool you could see also from where those methods were called. But bare in mind, that when you execute program, then it is not guaranteed that your interesting method is called from every possible place.
if you are developing an automated tool for displaying calling graphs of methods. Then you need to parse source and start working with code entities. One way would be to implement your own compiler and go on from there. But easier way would be to reuse opensourced parser/compiler/analyzer and build your tool around it.
I've used IntelliJ IDEA CE that has such functionalitys and may be downloaded with source http://www.jetbrains.org/display/IJOS/Home
Also there is well known product Eclipse that has its sources available.
Both of these products have enormous code base, so isolating interesting part would be difficult. But it would still be easier than writing your own java compiler and werifying that it works for every corner case.
For analyzing the bytecode as mentioned above you could take a look at JBoss Bytecode. It is more for testing but may also be helpful for analyzing code.
sven.malvik.de
You may plug into the compiler.
Have a look the source of Project Lombok for instance.
There is no general mechanism, so they have one mechanism for javac and one for eclipse's compiler.
http://projectlombok.org/
I want to define a few annotations that will allow extra warnings/errors to be reported during compilation (similar in concept to the #Nullable and #NotNull annotations in IntelliJ).
I would like to be able to write some compiler hooks that will also add my compilation logic based on those attributes.
I want a generic hook if possible, however since we are using Eclipse - it would also be a benefit if we had that ability.
I'd like to know:
Is it possible? (any of the options above)
Where do I start?
I had little experience with annotations so far, so if I'm going about this the wrong way - I'd like to know that and if possible get a better direction to go with.
Thanks.
You can use the Java Annotation Processor (see JSR 269: Pluggable Annotation Processing API) for that. From Annotation checking at compile time with Java Annotation Processor:
The JSR 269 states that you can
implement a plug-in for the compiler
which can handle the annotations. This
plug-in can be given as parameter at
compile time, so your code will be
called when one of your annotation
appears in source code.
The mentioned link provides an example that will get you started.
See also:
Annotation Processing Tool (apt)