Skip to main content

Apt conventions needed

6 replies [Last post]
regexguy
Offline
Joined: 2003-06-20
Points: 0

This is not really a language feature request, but we need to have some standard ways of using apt if it is going to be toolable and fit into IDE's.

How can IntelliJ/Eclipse/Netbeans know the file dependencies of apt generated files if we don't provide standard clues?

Consider that I have some tag named @ExtraReflection, and when I place it on a class named Foo an annotation processor named ExtraReflectProc generates a class called Foo_ExtraReflection.

I would propose that we standardize two tags, and mark the generated class with both of them. Namely...

1) @GeneratedBy(name="full.class.name") this tag would identify the annotation processor ("ExtraReflectProc" in my example above) so that any IDE could figure out that part of the dependency.

2) @GeneratedFor(names={"full.class.name"}) this tag would identify the "Foo" class in my example above. I put the tag in as a list, anticipating that some apt processors may produce a file based on several source files.

I think that unless something like this is advocated by Sun it will be difficult to integrate apt into the development process because it will become impossible to really write ant/make scripts.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jddarcy
Offline
Joined: 2004-11-02
Points: 0

See bug 5078183 "(ann) add a new annotation in java.lang : @Generated("generator")" for a request in the same vein.

jddarcy
Offline
Joined: 2004-11-02
Points: 0

See bug 5078183 "(ann) add a new annotation in java.lang : @Generated("generator")" for a request in the same vein.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

+1

In a similar problem space...

Maybe we need a better apt discovery process where there is a meta-annotation on annotations so the annotation tells apt what its processor factory is called (and a few other things which I won't go into here.)

regexguy,

Come on over to the rapt project and start a discussion on this, there isn't much traffic yet, but lets at least start to capture these ideas. Unless developer.java.com start a forum for apt (they have one for javadoc), we need a place to build an apt community. Rapt can be that if there is no where more obvious.

jddarcy
Offline
Joined: 2004-11-02
Points: 0

One of the envisioned uses of the -factory option is to allow alternative discovery processes to be experimented with. If you use -factory and the factory processes "*", that factory will be the only one queried and it will always be queried. The factory is then free to find and query other factories using its own policies.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

Thanks Joe,

Its nice to have an inside view of this. At this level of detail the documentation is a bit loose, and the rest of us are working with a black box, firing alpha particles at it and seeing where they bounce back. We then have to make a judgement about whether the observed behaviour is intentional (and therefore liable to remain), or a side effect (and therefore not such a good base to build on for the future).

Your comment is therefore very valuable to me.

jddarcy
Offline
Joined: 2004-11-02
Points: 0

> Its nice to have an inside view of this. At this
> level of detail the documentation is a bit loose,

Yes, the documentation about how to use apt could certainly be augmented. By design the getting started guide doesn't cover more advanced topics and there is not (yet) a more inclusive how-to.

Factories could have their own mini-discovery process as well, even if the default apt discovery process is being used globally. For example, if your factory processes 5 annotations, it could have some nontrivial procedure for determining the appropriate processor(s) to run for a given subset of those 5 annotations, combining multiple processors using an aggregate annotation processor.