This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Warnings from annotation processors when using -source 7 | ||
|---|---|---|---|
| Product: | platform | Reporter: | mgoe <mgoe> |
| Component: | -- Other -- | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anebuzelsky, gtzabari, jglick |
| Priority: | P4 | ||
| Version: | 7.1.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | AntLogger extension from which a Netbeans module can be created. | ||
|
Description
mgoe
2012-03-28 13:48:26 UTC
As far as I know it is harmless. It just means that NetBeans Platform modules, including those with annotation processors, were built against JDK 6 (since that is our baseline), and as such declared that they support (up to) SourceVersion.RELEASE_6. javac prints this warning when your module's source level is set to 1.7, because the compiler cannot assure that the processor will in fact work. The warning seems to be issued even without -Xlint, so short of using -nowarn it cannot be suppressed.
It is likely that all NB processors in fact work fine with RELEASE_7, since this had only relatively minor language changes with no effect on the Java element model (I just confirmed NbBundleProcessor works with -source 7). The processors cannot declare that they support RELEASE_7 without either
1. Using SourceVersion.valueOf("RELEASE_7") and falling back to RELEASE_6 in case of IAE - ugly.
2. Using SourceVersion.latest(), which is a bit dangerous since e.g. JDK 8 might change the language model in a way that actually forces updates to the processor to support some new constructs.
Of course you can simply switch your module to use javac.source=1.6 but then you cannot take advantage of Project Coin enhancements. 7184902 has discussion and requests an -Xlint category. Unfortunately jdk bug 7184902 is not publicly available. So you cannot vote for it. This bug is very annoying. When compiling our project with jdk7 we have hundreds of lines with these warnings. It is easy to miss "real" warnings. Perhaps you could provide a filter for the output until this problem is fixed. 7184902 just filed, should appear on the public site within a couple days - sorry for not mentioning that. Providing an output filter is not a bad idea. Could be done by any plugin implementing AntLogger. Thank you for your hint with the AntLogger. I implemented an AntLogger extension (see attachment) suppressing the following two message patterns (but can be extended by additional patterns): Supported source version ... from annotation processor ... No processor claimed any of these annotations: ... Best regards, Martin Created attachment 122191 [details]
AntLogger extension from which a Netbeans module can be created.
Please feel free to use this code for a fix.
The JDK issue was closed as "Not an issue" with no explanation. I've sent an email to Ingrid (of Oracle) asking for clarification. Thanks. The JDK bug tracker is rather opaque I am afraid. Jesse, Here is what I was told: > SupportedSourceVersion does not specify the minimum, but "the latest source > version an annotation processor supports". So, annotating with RELEASE_6 and > compiling with -source 7 is compiling with an unsupported version and a warning > is issued. > > This is behaving as documented. If you still want this filed as an RFE to add > an -Xlint option, please resubmit...no harm asking. How would you like to proceed? > This is behaving as documented. Yes; the issue is that this documented behavior is inconvenient. > If you still want this filed as an RFE to add an -Xlint option, please resubmit This is exactly what the original http://bugs.sun.com/view_bug.do?bug_id=7184902 suggested! Thus closing wontfix on NB side. Thanks. Resubmitted to Java team, number pending approval. Resubmitted and once again closed: https://bugs.openjdk.java.net/browse/JDK-8037955 The suggested workaround is to use if (SourceVersion.latest > RELEASE_6) return (SourceVersion.values())[RELEASE_6.ordinal()+1]; else return RELEASE_6 At this point of course RELEASE_8 should be considered as well, though the language changes have been substantial enough that there is a slight possibility that existing processors would need some fixes to support it. ergonomics#c45f8d78f9da bumps supported versions of processors I could find to 7. I will not solve problems compiling on JDK8 in this issue. Integrated into 'main-silver', will be available in build *201405130001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/c45f8d78f9da User: Jaroslav Tulach <jtulach@netbeans.org> Log: #210286: Updating all our processors to support version language version from JDK7, now when we no longer run on JDK6 |