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.
Related
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.
So, I may sound crazy when I say that I want more warnings in my Java code, but hear me out. I'm transitioning to better coding practices, and want the IDE to help. In my older days, I made a library in packages like bht.tools, but now am moving to org.bh.tools. To do this, I'm moving the classes slowly and one-by-one, so that I can also go over their code to make sure best practices are being used there too. This has the added benefit of knowing that any class I import from the new packages has recently been reviewed to be more robust and efficient.
In short, I want NetBeans to show a warning wherever I'm using bht., whether it be in imports, fully-qualified names, etc.. Is this possible?
Yes, you can use the Netbeans Java Hint Module. There is a nice tutorial here.
You probably need do define a TriggerPattern:
Find parts of the source code that satisfy the given pattern, and invoke the method that is annotated with this annotation. The method must be public static, the return type must either be assignable to ErrorDescription or to Iterable. Its sole parameter must be HintContext.
and also a JavaFix
A base class for fixes that modify Java source code. Using this class as a base class makes creating the fix somewhat simpler, but also supports running the hint in the Inspect&Transform dialog. The fix can be converted to Fix by means of the toEditorFix() method.
Read the official tutorial and the org.netbeans.spi.java.hints documentation for full details.
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.
Hi guys: Is there an open source way to associate java #annotations to functional requirements, or for example, TRAC tickets, etc? I want to do something like this:
I'm thinking along the lines of an eclipse plugin which somehow links up with another FOSS project tracking tool, wiki, or maybe even a CSV file.
A somewhat silly but exemplary illustration of what I desire is below:
#Requirement WalkDogTwiceADay
public void walkTheDog()
{
}
#Requirement WalkDogTwiceADay
public void dogWalkerThread()
{
walkTheDog(); //in the morning.
Thread.sleep(36000000);
walkTheDog(); //at night
}
Annotations are metadata, they simply add information to your code for other tools to use or to be inspected at runtime via reflection.
One thing you can do is write an annotation processor that will generate the necessary artefacts. Those could be configuration files, scripts, code...
Another thing you can do is write some tool that knows how to interpret your annotations and uses reflection to find them and take the appropriate actions. For this you'd need to make sure that the annotation type is set to have runtime retention, as opposed to only source or class.
Perhaps some of the stuff found in the answers to this question might prove of use. If that's the case, go ahead and use it. But writing custom annotation processors or code for handling them is not all that terribly hard. The difficult part is getting to know the Java model API that's used by annotation processors, which is like reflection but at compile time (before you have fully-formed classes).
in a previous life, we did something similar with #requirement ##### annotations, and then had a custom javadoc task that turned the requirement annotations into hyperlinks in the javadocs.
I was going to write an addin for eclipse that turned them into links in the code as well, but never got that far.
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)