> For Jooq, the easiest way would probably be adding annotations > on classes, members, and test cases - could be named @Eternal or > something. > Something annotated @Eternal would be there to stay, even in Jooq > 42.0. Something without that annotation might get deprecated, or > have slight semantic changes.
I've been investigating the possible applicability of such an @Eternal (or as I prefer @Internal) annotation. On this user group, we had discussed the potential usefulness of the current @Support annotation as well, which indicates whether some method / type is supported in a given SQL dialect. I would like to evolve jOOQ in a way that annotation processing at a compiler level is possible. These things are done in frameworks like - Project Lombok (http://projectlombok.org) - Checker Framework (http://types.cs.washington.edu/checker-framework) The latter is a really interesting case, where things like nullability are statically analysed by the compiler through annotation processing. What I would like to see is this: - jOOQ has @Internal and @Support annotations - client code can activate such annotation processing for either javac and/or Eclipse - The compiler would then emit warnings that can be suppressed specifically if needed An interesting insight is given here, in this question (although the warning is emitted at the callee-site, not the call-site): http://stackoverflow.com/q/1752607/521799 Does anyone have any experience with javac's APT API? Is anyone interested in providing a contribution in that field? Cheers Lukas
