The compiler could look at the Imports when resolving Annotations and the value of Class-Fields

we provide the annotation.properties mapping file for that purpose (only optionally needed at compile time)

I understand that the solution provided by the annotation.properties file is adequate for the huge majority of use cases, so there's no big need for this extended feature I'm describing here.

But the solution with the properties file is not sufficient for us, because:

• it doesn't handle the "(clazz=SomeClass.class)" case, especially since "SomeClass.class" is not limited to any specific set, so the possible choices can't be listed in the properties-file.
• it doesn't allow the case where some source files refer to MyAnnotation and others to p2.MyAnnotation. (We've got a case where we got an Annotation that's named "Attribute". Some classes handle another class that's also called Attribute. There the other Attribute is imported and the annotations use the fully quallified name).

This feature would basically bring Backport175 annotations closer inline with how JDK1.5 handles backports and would thus ease migration (in both directions), which I'd consider a good thing.

So I'd ask if you'd consider accepting a patch, if I were to implement this (which I can't promise yet).

A patch would make sense if this feature is not tied to the plugins (Eclipse or IntelliJ) but to the core module - hence the one that depends on QDox.
As a side effect often in IDE you can refactor the import to remove the unused one. Doing so may lead to removing a used annotaiton that is seen as unused since in the form of a doclet. Those problems would then be quite hard to catch (or would inevitably trigger issue as soon as the user refactors his imports)

I'm aware that refactoring (such as Eclipse "Organize Imports") would remove such imports. In our special case that's not a problem, as the original code is 1.5, where the imports are used and the pre-processed code is only created during the build process, so noone is tempted to use these refactoring methods.

I've created an initial patch that solves the first part of this feature: It allows the Annotation Type to be resolved using the imports. It doesn't try to resolve values of type java.lang.Class with this method, yet, because that seems to be done in the parser (which I haven't looked at yet).

I've attached the new patch. It's not as small and self-contained as I liked it to be. That's probably because I know little of the internal working of Backport175. If someone with greater knowledge of the system could review it, I'd be grateful. It works for the TestCase I've added to the patch (and doesn't break any of the other tests ).

I've put the helper method that resolves imports into the AnnotationInterfaceRepository, mainly because that's where I've started my work and because it already got a similar helper method (handling nested classes). This should probably be moved somewhere, where it's more fitting (AnnotationC, maybe).

Ok, I spoke to early ... it seems I've created a broken patch and forgot to correct some places. I've got a real working version now, but somehow the CVS server doesn't seem to be willing to create a working patch for me. I will investigate this tomorrow.

This is the patch that I've applied that runs the ant-file with the tests successfully (it still fails with 2 tests, but that tests always fail for me, even with pristine sources).

There seem to have been some encoding troubles at my end, so if you've got trouble applying the patch, tell me and I'll try to find another solution.

That sounds great but I am still frighten by such a mode.

Jonas what do you say ?

I would accept is only with an explicit option "-useimports" or something like that in the command line / Ant etc
(and then use it by default in the IDE or don't use it at all ? Right now IDE plugins don't expose compiler options)

If IDE don't use it then valid source won't appear valid.
if IDE use it, then mhh, experience won't be that perfect without mechanism that hooks that with the import refactoring of the IDE - something that I don't want.

As I said, this all can be handled in a properties file in a much more robust way.

won't fix - too dangerous due to IDE refactoring side effect