We Keep Coding

Java annotation that sets target as "used" [duplicate]

IntelliJ IDEA has a handy feature to detect unused methods and show them in grey, hinting a potential warning for dead code.
Some methods, however, are not executed directly but via reflection. A good example would be #RequestMapping-annotated methods which are executed by Spring. IntelliJ has decent Spring integration hence it detects this annotation and does not mark such a method as unused.
I have a tiny AJAX framework where I use my own annotation to point which method to execute based on certain HTTP request properties (very similar to what #RequestMapping is doing). Understandably, IntelliJ has no idea what does my annotation stand for and and marks such a method as unused, adding unnecessary noise.
I was thinking of:
annotating my annotation with another annotation, but are there any standard ones that would do the job without any extra effort?
finding a particular setting in IntelliJ to identify custom annotation for marking methods as used, but this would require other team members to do the same, basically a pain.
Can anyone suggest any ideas how to solve this problem?

You can tell IntelliJ to not to warn about used for any method/field annotated with the annotation the "unused" method has.
It should be a quick fix all you have to do is hit <Alt>+<Enter> and select Suppress for methods annotated by ...
You don't need to add anything to you code and you only have to do this once per annotation.

#SuppressWarnings("unused") should work.

#Peter Lawrey s solution did not help in my version of Intellij (14.1.1).
I used the hard way around:Settings-Editor->Inspections->Unused declarion
Now there is an Options point, scroll down to Configure annotations... and you can add your annotation there.

In the "Settings" you can "uncheck" Settings - Inspections - Declaration redundancy - Unused Declaration code inspection.

Adding programmatic annotations to a Java class

Usage example:
I want to put on class fields a custom annotation #MyContainer and then add automatically on all such fields relevant Hibernate annotations (depending on field type and properties).
In additional I need to add JAXB XmlType annotation to the class and base the type name on the class name.
I would want additionally to add annotations to fields based on thier types, etc.
All added annotations should be available at run time (So hibernate / JAXB can find them).
I'm aware of the following options:
Pre-processing class source (bad option)
Processing during compilation with javax.annotation.processing APIs
Post compilation manipulation with tools such as Java Assist
Manipulation during class loading with java.lang.instrument APIs
Doing it with AspectJ (not powerful enough)
My primary goals are:
Keep sync between class and source for debugging
Support working from both Maven and IDE (Eclipse / Intellij)
I'll appreciate if people who already done such things can recommend the best approach for such a task (and perhaps potential pitfalls).

Here is a code example for defining custom annotation. This #TesterInfo is applied on class level, store the tester details. This shows the different use of return types – enum, array and string.
package com.mkyong.test.core;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
#Retention(RetentionPolicy.RUNTIME)
#Target(ElementType.TYPE) //on class level
public #interface TesterInfo {
public enum Priority {
LOW, MEDIUM, HIGH
}
Priority priority() default Priority.MEDIUM;
String[] tags() default "";
String createdBy() default "Mkyong";
String lastModified() default "03/01/2014";
}

I think pre-processing class sources should be your preferred way. This enables you to have your sources in sync with the compiled classes, which is good for debugging as you mentioned. But it is also good for version control, since you are able to check in those generated annotations. It is also a lot more difficult to track down problems in your tool, if it is run it during compilation. IDE support should also be no problem when running your code generation in the generate-sources phase.
Edit:
Quick searching yielded some infos about programmatic java source modification
using the eclipse jdt or some thing in netbeans. But this might be worth some more research or a question of its own.

I want to suggest another approach on that. As my first answer might involve coding an own tool, you could also try a much simpler solution. As I hope you are unit testing your classes, you could implement a base class for every unit test of such a class. In this base class there is a test method, which checks that every field annotated with #MyContainer also has the required hibernate annotations.
We basically did the same thing, not for annotations but for serializability of fields and ran quite well with that approach.

To have it work most transparent in IDE, command line build and at run-time, option 1 (using APT) and option 5 (using AspectJ) will give you best fit.
For option 1 you'll have to implement your own annotation processor that will inject additional annotations based on the presence of your own #MyContainer annotation. Here is an example of this approach used for something similar.
For option 5 you can simply use annotation declaration. Something like this:
declare #field : * ((#*..MyContainer *)).*(..) : #OtherAnnotation();
Spring's Roo tool is extensively using option 5 and I certainly can't say it is not powerful enough.

There are few alternatives as mentioned above and each have its upsides and downsides. That's why I don't think there a real "right" answer for the above question. My purpose was to get inputs from the community and from people who had done such things in the past and have experience. Personally I've chosen to use the Instrument API with Javassist. This way the classes are extended on run time (although the same tool can be used for post compile processing). The nice thing is that the agent can be loaded from inside the JVM which avoids handling all the command lines. It will be great to hear on other alternatives.
Thanks,
Avner

Telling IntelliJ IDEA which methods not to identify as unused

IntelliJ IDEA has a handy feature to detect unused methods and show them in grey, hinting a potential warning for dead code.
Some methods, however, are not executed directly but via reflection. A good example would be #RequestMapping-annotated methods which are executed by Spring. IntelliJ has decent Spring integration hence it detects this annotation and does not mark such a method as unused.
I have a tiny AJAX framework where I use my own annotation to point which method to execute based on certain HTTP request properties (very similar to what #RequestMapping is doing). Understandably, IntelliJ has no idea what does my annotation stand for and and marks such a method as unused, adding unnecessary noise.
I was thinking of:
annotating my annotation with another annotation, but are there any standard ones that would do the job without any extra effort?
finding a particular setting in IntelliJ to identify custom annotation for marking methods as used, but this would require other team members to do the same, basically a pain.
Can anyone suggest any ideas how to solve this problem?

You can tell IntelliJ to not to warn about used for any method/field annotated with the annotation the "unused" method has.
It should be a quick fix all you have to do is hit <Alt>+<Enter> and select Suppress for methods annotated by ...
You don't need to add anything to you code and you only have to do this once per annotation.

#SuppressWarnings("unused") should work.

#Peter Lawrey s solution did not help in my version of Intellij (14.1.1).
I used the hard way around:Settings-Editor->Inspections->Unused declarion
Now there is an Options point, scroll down to Configure annotations... and you can add your annotation there.

In the "Settings" you can "uncheck" Settings - Inspections - Declaration redundancy - Unused Declaration code inspection.

Tool to identify Java annotations in various Java APIs

I'm trying to identify places where annotation names are the same or similar to compile a list of these things to make sure our team knows where possible points of confusion can be found. For example, Guice #provides and RESTeasy #provider are similar enough in spelling but different enough in semantics as to confuse people so I'd like to call that out explicitly and explain the differences.
What I'm looking for is a tool or even a website that enumerates the annotations associated with packages. This might be a pipe dream, but before I manually start going through and collecting these things I thought I'd check.
I was considering writing one based on Javadoc that simply only pulled in the annotations but I don't have access to Java source files in many cases.
Any thoughts or suggestions?

In Eclipse you can use the standard method "Search for references" (context menu of a used annotation References -> Project) and you are getting a list where the annotations is used within your project.

I suggest to scan for annotations yourself and generate a list for that.
You can do that by writing your own implementation of an annotation processer, i.e. extend AbstractProcessor. Within this processor you can write a text file containing all Annotations. You can add this processor to your build procedure, then it will execute the processor when you build the project.
Another way to do this is using the Google Reflections library. This might be a bit more work since you would need to write a small programm to fetch the annotations and write the file.

I wrote such a tool: https://github.com/MoserMichael/ls-annotations
it decompiles the byte code and lists declarations (classes, functions, variables) with annotations only. You can also use it to find all classes/interfaces derived from a given class/inerface - and all the classes/interfaces derived from a given class/interface.
The tool uses the asm library to scan class files and to extract annotations. it can detect annotations with retention policy CLASS and RUNTIME. It can't detect annotations with retention policy SOURCE that are not put into bytecode, for example #Override is one of these.

Why not scanning your classpath and export all used annotations? Then just use some simple parsing / text compare to see the elements with almost the same name?

Maintainability of Java annotations?

My project is slowly implementing Java annotations. Half of the developers - myself included - find that doing anything complex with annotations seems to add to our overall maintenance burden. The other half of the team thinks they're the bee's knees.
What's your real-world experience with teams of developers being able to maintain annotated code?

My personal experience is that, on average, dealing with annotations is far easier for most developers than dealing with your standard Java XML Configuration hell. For things like JPA and Spring testing they are absolute life-savers.
The good thing about annotations is that they make configuration on your classes self-documenting. Now, instead of having to search through a huge XML file to try and figure out how a framework is using your class, your class tells you.
Usually the issue with changes like this is that getting used to them simply takes time. Most people, including developers, resist change. I remember when I started working with Spring. For the first few weeks I wondered why anyone would put up with the headaches associated with it. Then, a few weeks later, I wondered how I'd ever lived without it.

I feel it breaks into two uses of annotations - annotations to provide a 'description' of a class vs. annotations to provide a 'dependency' of the class.
I'm fine with a 'description' use of annotations on the class - that's something that belongs on the class and the annotation helps to make a shorthand version of that - JPA annotations fall under this.
However, I don't really like the 'dependency' annotations - if you're putting the dependency directly on the class - even if it's determined at runtime from an annotation rather than at compile time in the class - isn't that breaking dependency injection? (perhaps in spirit rather than in rule...)
It may be personal preference, but I like the one big XML file that contains all the dependency information of my application - I view this as 'application configuration' rather than 'class configuration'. I'd rather search through the one known location than searching through all the classes in the app.

It depends highly on IDE support. I feel that annotations should be kept in sync with the code via checks in the IDE, but that support for this is somewhat lacking.
E.g. the older version of IDEA would warn if you overrode a function without #Override, but wouldn't remove the #Override tag if you changed the method signature (or the superclass signature, for that matter) and broke the relation.
Without support I find them a cumbersome way to add metadata to code.

I absolutely love annotations. I use them from Hibernate/JPA, Seam, JAXB....anything that I can. IMO there's nothing worse than having to open up an XML file just to find out how a class is handled.
To my eye annotations allow a class to speak for itself. Also annotations are (hopefully) part of your IDEs content assist, whereas with XML config you are usually on your own.
However, it may come down to how the XML configs and Annotations are actually used by any particular library (as most offer both), and what sort of annotation is used. I can imagine that annotations that define something that is build-specific (eg. file/url paths) may actually be easier as XML config.

i personally feel that the the specific use case you mentioned (auto-generate web forms) is a great use case for annotations. any sort of "framework" scenario where you can write simplified code and let the framework do the heavy (often repetitive) lifting based on a few suggestions (aka annotations) is, i think, the ideal use case for annotations.
i'm curious why you don't like annotations in this situation, and what you consider to be the "maintenance burden"? (and, i'm not trying to insult your position, just understand it).