I got this error and just can't seem to find how to get it working.
My code, simply following some Vaadin10+ exercises:
#PropertyId("string")
final TextField stringField = new TextField("A simple string");
and this won't compile, highlighting the annotation telling the error I put as a title of this question. Compilation error doesn't tell anything more.
Any idea of why it doesn't work? For reference, this is a maven project in eclipse (LTS) and Java 8, and I don't lack any dependency in the pom since I copied the working copy of the pom from the exercise files archive.
Anyway, I'd only need this to do bean validation with javax validators, so I don't need it that hard. I'd just like to understand why it breaks.
The error message you're referring to happens e.g. when an annotation declared to be used on methods is instead used on e.g. a class or an instance field.
#PropertyId in Vaadin is defined with #Target({ ElementType.FIELD }) which means that it should be used for instance fields. Since you are not showing the full context of the code that causes the problem, I can imagine two potential causes:
Your stringField is a local variable inside a method instead of being an instance field in a class.
You're accidentally importing some other #PropertyId annotation instead of the intended one from com.vaadin.flow.data.binder.PropertyId.
Related
Say I have a Module structure like this:
Root
|--SubModuleA
|-BaseModule
|--SubModuleB
|-BaseModule
SubModuleA and SubModuleBare intended to be used seperatly but also in one application like in this example. And both install the same BaseModule.
Guice allows to declare the same bindings several times if they are exactly the same. In another SO-thread this is referred to as "binding de-duplication".
This works fine for simple bindings, but using a FactoryModuleBuilder in the BaseModule results in a CreationException complaining that
"A binding to ... was already configured at [...]FactoryModuleBuilder$1.configure()"
I checked, that the binding really is declared only in one Module. And removing the binding results into an error stating that the binding is missing. So I assume that it is not possible to declare the same binding more than one time using a FactoryModuleBuilder. Is that true? Is there a way around this?
Yes, you can get around this by instead doing
Root
|--BaseModule
|--SubModuleA
|--SubModuleB
All modules together define the registered bindings of the injector. Only in special cases should it be actually necessary to install another module inside of a module, apart from readability.
I have a Kotlin object that has several fields exposed as static #JvmFields. The parser that I use (which I cannot edit or change) looks for public static fields and creates a configuration file based on those. Since the INSTANCE field is public too, the parser generates a new category called instance. Is there a way to add actual annotations to the INSTANCE field? I would want to add the #Ingore annotation to it so the parser does not use the INSTANCE field.
Basically, the answer is no, Kotlin does not allow annotating or altering the INSTANCE fields in any other way. If you believe this could be a useful feature, please file a feature request at kotl.in/issue.
The valid solutions to this problem are:
Make the bytecode analyzing tool Kotlin-aware, i.e. make it behave correctly with Kotlin declarations. Though this requires non-trivial job to be done and does not seem possible in your case, it could be a valuable time investment.
Create another ad-hoc tool that post-processes the classes produced by the Kotlin compiler and adds the annotations you need, then include that tool into your build.
I recently switched to IntelliJ IDEA from Eclipse and I really like the inspectors and find them marking potential errors with warnings for me really useful. I ran into a problem with them that I am unable to solve:
I have some Java projects that are used as APIs in other project, therefore it contains unused methods, which are marked as such:
Unused warning
How can i suppress this for the API methods? Is there an alternative to #SuppressWarnings("unused"), since this also suppresses warnings about unused warnings inside the method and doesn't make it clear to the reader that this method is designed for API use instead of just not being used in the current project?
#Sebastian's suggestion to have your class implement an interface is probably the best way to solve this issue from a good design standpoint. But when that is impractical, there is an alternative...
The "Unused declaration" inspection allows you to configure "entry points" (i.e. a public external API) to ignore. As part of that you can configure "annotations". Anything annotated with the configured annotation is seen as an entry point.
Just configure the inspection to use an annotation that you annotate your public API methods with, either one from a library -- such as #API Guardian (used by some open source projects such as JUnit 5) -- or one you create. Using a library will of course make things easier and consistent across projects. In the below example I used a #PublicApi annotation I created. Notice the method is not highlighted as unused. But the foo String still is highlighted as unused, which is what you want:
As an alternative to opening the Settings dialog, and to limit the impact on your programming flow, you can also use a Quick Fix Intention to add the desired annotation to the "Unused Declaration" settings. After annotating with the desired annotation, place your cursor on the highlighted unused method (or class) name, and invoke the "intention actions and quick-fixes" popup via Alt+Enter or ⌘↩ (or by clicking on the light bulb icon ) and select "Suppress for methods annotated by '{annotation}':
Write an interface for your class. Methods that implement an interface method are not marked as unused. instead the unused methods from the interface are marked as unused but here you can safely use #SuppressWarnings("unused") because you do not have a method body. You could even write #SuppressWarnings("unused") above the whole interface.
In short, no and this isn't really anything to do with IntelliJ, Javac the Java compiler will produce these if you ask it to.
If your method needs this annotation, then that will be for the entire method. However if you just wish a field to be annotated, then that is possible:
#SuppressWarnings("unused")
int iii = 0;
In summary, the method annotation will cover the whole method, placing it per field or instruction will cover that single line.
intellij can do this for you.Just hit Alt+Enter on the occurance that gives you the warning. Some suggestions will pop-up one of them being remove field. there will be an arrow field at the end of the suggestion. Using your arrow keys navigate to the option and use the right arrow to bring up another menu. One of the options will be suppress this for method and suppress this for statement etc.
Suppress for statement will cause this :
//noinspection unused
int iii = 0;
However I have to urge you to heed to the warnings being provided by Intellij and not blindly suppress them.
I have a custom generator that generates code only for somes classes in my project. The following code is at the beginning of the generate method, and puts all the classes I will need to work on in the clazzes list
TypeOracle oracle = context.getTypeOracle();
JClassType markerInterfaceType = oracle.findType(MY_PARENT_CLASS.class.getName());
List<JClassType> clazzes = new ArrayList<JClassType>();
for (JClassType classType : oracle.getTypes()) {
if (!classType.equals(markerInterfaceType)
&& classType.isAssignableTo(markerInterfaceType)) {
clazzes.add(classType);
}
}
This code has been unchanged for more than a year, but since last week it seems that a few classes are not taken into account by the generator.
After some digging, i found that those classes are not even in the list returned by oracle.getTypes()
Those ignored classes are not newly created classes (some were left unchanged for several month)
As far as i can tell, there is no way to differenciate a class that will be ignored from any other class
No upgrade in our gwt version was made (some of us are using 2.5.0, others 2.5.1)
No upgrade in packages used by those classes either
oracle.findType(MISSING_CLASS.class.getName()) returns null
the problem appears only for some people, but not on the same classes
renaming problematic classes seems to correct the problem
My best guess would be that i have a cache problem somewhere, but i have no idea where to look.
As Mark Tielemans stated in his comment, delete your gwt-UnitCache directory (should be at the root of your project if you're using Eclipse) and rebuild. That should correct the issue for you.
Maybe too late for the answer but I was facing this issue for the last 3 days. No amount of clearing gwt-UnitCache folder was helping. Finally found the problem. The class which was not getting picked up by oracle had a reference of a gwt-ext class and I had not inherited gwt-ext in my module definition(.gwt.xml file). Removing that reference fixed the problem. So, using anything in your class which might not be referenced in your module definition or is not part of can cause your class not getting picked up by Oracle. Cheers!
The missing class doesn't compile right and that silently fails. A typical cause is super sources, because otherwise the normal java compilation would have already failed compilation.
This question asks how to figure out what line is actually failing silently inside that missing class.
I know that it's not possible to extends Java annotations.
I've created an annotation for a private field which means that the field is likely to appear unused in the class in which it is declared. For this reason, I'm getting a lot of "unused field" warnings on my annotated fields.
Is there any way to give my annotation the behaviour of #SuppressWarnings("unused") so I don't have to doubly-annotate every field which has #MyAnnotation?
The quick answer is "no". Java compiler doesn't know anything about your annotation, so it won't process it the way you want.
But the honest answer is "yes". In this article you can find detailed description of how to write compiler plugin. Chances are you can write plugin, which, in case of finding your annotation, will handle it and won't pass field to unused checker.