I'm working on a module project in NetBeans 8.2, with a GUI and everything. I'm using lots of the IDE functionality to auto-generate code for the GUI.
Every time I do a clean build of my project, I get a warning from the compiler:
warning: No processor claimed any of these annotations:javax.annotation.Generated
Browsing the build directory, I see that the IDE generates a class for me, Bundle.java, and it slaps the given annotation on top of it:
#javax.annotation.Generated(value="org.netbeans.modules.openide.util.NbBundleProcessor")
I need this warning to go away. I tried searching the web for an annotation processor that processes this specific annotation but I had no luck. Does an annotation processor for this specific annotation exist?
If this is a "harmless warning," I need to understand why it is harmless to justify its existence in my build output.
If needed I can include in this question the argument to the -processorpath option that is passed to javac from the IDE; I didn't include it on purpose because it is very long but I can add it if necessary
EDIT #1:
I did a "hacky" modification to the common.xml file under the NetBeans installation directory to make the invocation to javac not include the -processorpath option, and doing so makes the warning dissapear. I still do not understand why that is the case
A simple fix for this is to remove the #Messages annotation from the TopComponent class that is generated by the NetBeans code generator. It is that annotation that is responsible for generating the Bundle class, as per the NbBundle.Messages API Documentation.
As soon as you remove that annotation, you might get warnings from other annotations that rely on the contents of the #Messages annotation (i.e. TopComponent.OpenActionRegistration), so make sure to modify the contents of those annotation as well until nothing in your code depends on that Bundle anymore.
Hopefully nothing else in your code relies on your Bundle.
Related
Motivation:
In our code we have a few places where some methods are run by their name. There are some big if-else-if blocks with each function name and call of the corresponding method (I use the term function to describe just names, for example function X01 might correspond to method SomeClass.functionX01). I've been looking into ways to improve that
Goal:
Write just methods that are annotated with some custom annotation, removing the need to update or even include if-else-if blocks in order to run specific function. Have access to any generated code if any code is generated.
What I did:
I've created first prove of concept using runtime annotations and it proved successful, but slower then if-else-if. Next attempt was with source annotation
I've followed this link for an example, however it did not seam to run in IntelliJ. What I wanted is to have - in this case PersonBuilder class generated, instead there was none. In some cases an error was raised Error:java: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider BuilderProcessor not found
After some Googling and failing to find anything I've turned to book (Core Java, Volume II - Advanced Features - 9th Edition, Polish translation) and there was reccomended to run the following commands:
javac [AbstractProcessor implementation]
javac -processor [Compiled Processor] [other source files to compile]
This worked, however is unsatisfactory as it needs to happen inside IDE (NetBeans and IntelliJ to be specific) automatically during build. Code does not need to be generated on the fly, but programmer must have access to it after build (as in - be able to call methods of generated classes)
Question:
How to have and use generated code used in NetBeans and IntelliJ without the need of using external tools? Is it possible, or using reflection, runtime annotations or external tools is the only way?
Additional info (just in case):
Language level: Java 1.8
JVM versions: 12 and 13
IDEs: NetBeans and IntelliJ
I'm trying to get NonNull annotations working in NetBeans, and it's been one headache after another.
I followed the instructions at https://checkerframework.org/manual/#netbeans and can confirm that checker-qual.jar is added as both a compile and processor library. I've enabled annotation processing and added org.checkerframework.checker.nullness.NullnessChecker as an Annotation Processor.
In the source code I can import import org.checkerframework.checker.nullness.qual.NonNull and have #NonNull annotations compile. However while building I get this:
error: Annotation processor 'org.checkerframework.checker.nullness.NullnessChecker' not found
What do I need to do to resolve this error?
The instructions for the NetBeans processor path are incorrect: they first talk about adding checker.jar, but then mention checker-qual.jar https://github.com/typetools/checker-framework/blob/master/docs/manual/external-tools.tex#L904
checker.jar contains the actual annotation processor and should be put on the processor path.
I'll update the instructions.
However, we did not yet find a way to add the annotated JDK jdk8.jar to the bootclasspath that the processor uses. Therefore, none of the JDK annotations that are provided will be visible within NetBeans. We will therefore need to remove support for the Nullness Checker from NetBeans, until we find a proper solution.
I've recently discovered Error Prone and am integrating it into my Android build using the Gradle plugin linked on their page.
Since our project is using Icepick (and some other code generating annotation processors), we have generated source code, which gets compiled in. Unfortunately, some of the generated code triggers warnings in Error Prone, and I'd like to filter that noise out somehow.
The generated code shows up in the app/build/generated/source/apt/debug directory. How can I exempt this code from Error Prone's steely gaze?
Use the flag -XepDisableWarningsInGeneratedCode
See this issue on GitHub
In my case classes were annotated with #AvroGenerated and -XepDisableWarningsInGeneratedCode didn't work.
The solution was to exclude build directory from checks via -XepExcludedPaths:.*/build/.*
I'm developping an annotation processor to generate some code but I'm having some compilation issues.
I'd like to be able to use the generated classes in the same module where the annotated interface that triggers the generation is located.
This does not work on the first compilation after deleting all generated sources though, although I thought that annotation processing should be run before compiling other sources.
So the references to the generated sources generate an error on the first run, stating the generated packages do not exist.
On a second run everything compiles fine, but I suspect the generated sources from the previous run are used, not the newly generated ones.
Am I perhaps missing some mechanism to configure this? Or is this expected behaviour?
The issue and it's solution are described here: https://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
The key is to wrap the code generation with
if (!roundEnv.processingOver()) { ... }
to avoid changing the generated files in the last compiler round.
I get the following IDE error which appears inline or on the package declaration of my classes, but doesn't prevent the code running or working as expected.
I tried manually downloading the javax-annotations.jar from Glassfish and placing that in both the classpath and also on the JDK external JAR resources areas, no help.
The type javax.annotation.meta.When cannot be resolved. It is indirectly referenced from required .class file.
The error appears anywhere that I use the Findbugs #NonNull annotations; any class which uses this annotation has the above message appear in the IDE on the package declaration line. The class however appears as error-free from the Package-Explorer or Navigator view.
I would quite happily ignore this, however it breaks the Mark-All-Occurences behaviour which I quite like, if anyone has any ideas on what I might have missed I would appreciate it!
The FindBugs jar already contains a jsr-305.jar, which contains an implementation of JSR-305.
More info in this previous question.
Edit Oh, you already did that--I didn't even know it was in annotations.jar as well.