How should I maintain JDK7 projects, so that they automatically could be downgraded for JDK6?

Question

I have few own APIs with around 2000 classes overall. Some of them use the new Path API from JDK7. Most other classes, however, do not rely on any new JDK APIs or new language features. So most classes could be used in a JDK6 environment (which I plan to do). Let's assume, I've annotated all JDK7-only classes with @Java7Only.

What I need now, is a way to create a JDK6-only subset of all my projects more-or-less automatically, without introducing new version branching or product lines (would be too complicated to maintain).

All projects are created using Netbeans, thus using Ant. Many projects depend on others.

Please help me evaluate, which ideas according to my problem is most appropriate. Which problems could occur with each idea?

Common first step for all ideas

• Let an annotation processor search for @Java7Only-annotated classes and store the list to a properties file.

Idea 1 (specific)

• Write a tool which would use the properties file to recursively copy the whole project, except JDK7-only files.
• Build the copied project using JDK6 by invoking ant, thus getting a JDK6-compliant jar.

Idea 2 (specific)

• Write a second annotation processor which would use the properties file to pass everything except JDK7-only files to a JavaCompiler instance.
• Either build a jar using Java APIs or use Ant API for that.

(This would be a Java-only idea, but probably too complicated)

Idea X (abstract)

• Somehow influence the Ant build process (by overwriting some targets?) and for each JDK6-compliant class: let Ant compile two versions of it (one time with JDK6 compiler, another time with JDK7 compiler).
• (JDK7-only classes would be compiled only once, using the JDK7 compiler, of course)
• Package each bunch to a separate jar.

Possible common problems to the ideas

• Some projects dependent on others, so some actions (such as packaging) should consider this.
• Remember: the JDK7 compiler generates downward incompatible class files, that's why every possible idea has to happen on sources-level (before or during the build process, not afterwards).

Answer 1

This only partially applies but I'd thought I'd mention it anyway.

The problem with just using -source 1.6 -target 1.6 options for validation is that you can still use Java 7 API when compiled using JDK 7.

I've used the Animal Sniffer Maven Plugin for a few projects now and it has proved quite useful. This plugin scans byte-code of your classes for JDK API usage. That is, you can tell it to fail the build if you attempt to use JDK 7 API when you are targeting JDK 6. This wont help much for separating out classes as you need but it could be useful as a final validation step combined with -source 1.6 -target 1.6 compiler options.

There is also an animal sniffer Ant plugin, as mentioned from the Animal Sniffer main page.