Here is my use case. Suppose annotations did have inheritance and would automatically inherit the entire behaviour of the base class. Then I would do the following (note the two package statements):

package cdiswitcher.precdi;
public @interface SessionScoped extends javax.faces.bean.SessionScoped {}
public @interface ManagedBean extends javax.faces.ManagedBean {}

package cdiswitcher.cdi;
public @interface SessionScoped extends javax.enterprise.context.SessionScoped {}
public @interface ManagedBean extends javax.inject.Named {}

The same for various other annotation pairs such as @ejb and @inject. This would simplify switching between the two bean injection systems: Just replace every instance of cdiswitcher.precdi by cdiswitcher.cdi, or vice versa.

Another use case might be extending the behaviour of an annotation, perhaps even creating a single new annotation that has the same effect as two existing ones.


Inheritance is not allowed with annotations. However, there is a way to do what you are trying to do, but it may or may not be worth the effort.

You could write a build script that performs regex replacements on your source before compiling. This could change annotation names and import packages dynamically. I would suggest not importing packages if you do this, so you only need to replace text at one location in each file. The less magical text replacement you perform, the better

This is not a good solution, but it is a valid solution. In general, source code should either be manually created or dynamically generated, not some freakish combination of the two. Personally, I would try to change the requirements. It might be more sane.

| improve this answer | |

For your particular problem, you can write a CDI extension to find beans with your custom annotation (or the base annotation you're find-and-replacing) and use it to modify the bean definitions in the deployment. For example, the CODI library (as I recall) does this to re-use @javax.faces.bean.ViewScoped for its own custom view scope.

With this theoretical extension you could write classes using JSF 2 annotations and run them in a CDI project without modifying the code.

Switching between @EJB and @Inject is not quite as simple as they work differently in some ways and don't really work as direct replacements for each other.

If possible, it would be much simpler to write the shared classes as simple POJOs, then write a CDI wrapper and a JSF wrapper as separate JARs, so the implementation isn't tied to any container in particular.

| improve this answer | |
  • Thanks! The first two paragraphs sound like a good answer. I am just not sure if I should officially accept it under the circumstances: We did in fact do the switch all at once, after resolving some initial problems. So I no longer have an immediate use for an answer, and don't have the time to this path out. I would expect to run into documentation issues and problems with IDE integration. – user144228 Mar 13 '15 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy