In eclipse, I get the following errors in my project:
The annotation #SuppressWarnings is disallowed for this location
Can you please tell me how can I turn those errors into warnings?
Thank you.
Look like it is a bug in eclipse3.6M5. This is the code which gives me error. But it works fine in eclipse3.6M4.
package java.lang.annotation;
/**
* Defines a meta-annotation for indicating that an annotation is automatically
* inherited.
*
* #since 1.5
*/
#Documented
#Retention(RetentionPolicy.RUNTIME)
#Target(ElementType.ANNOTATION_TYPE)
public #interface Inherited {
}
If it's really a wrong location of the #SuppressWarnings then there is not much you can do. But why should you turn that off?
As any annotation you can use #SuppressWarnings only in front of a class, a variable declaration, a parameter or a method declaration. All other locations will give you a compile error.
Project -> Properties -> Java Compiler -> Errors/Warnings.
Choose Annotations.
Change "Unhandled token in '#SuppressWarnings':" to Ignore.
Rebuild your project and this irritant will go away. Dirty - but given that this masks other issues in the project and waists time probably worth the time saved.
Related
I am having an issue in Eclipse (with Dagger 1 still).
In dagger, for dependency injection (javax.inject), you create a Module class, with provides methods, like this:
#dagger.Module
class FooModule {
#dagger.Provides
Something provideSomething() {
return new Something();
}
}
And this will generate a class (using annotation processing) called FooModule$$ModuleAdapter$ProvideSomethingProvidesAdapter.
If I set a breakpoint in a provideSomething method in FooModule class (my code), Eclipse almost always actually stops on that same line number in the FooModule$$ModuleAdapter$ProvideSomethingProvidesAdapter class instead.
Does anyone know how to avoid this problem? I suspect this is likely an Eclipse issue where it is somehow is mapping the generated file to what it thinks is the "source" file, but that's of course not what I want.
Is there perhaps some setting in eclipse to avoid this problem?
In a nutshell, if I define a constructor in a class thats named after the same name as the file itself, it returns the following area.
Some example code. Take the filename as ParseWebsiteData.scala for both.
This returns an error.
class ParseWebsiteData(url:String) {
}
This however, works fine.
class Foo(url:String) {
}
The only thing that I'm seeing as the issue are parser bugs from 2013, but this is the latest version of Eclipses's Scala IDE setup so I'm strongly thinking this is not the case, but turns out I'm wrong. Oops :(
As it's still an issue, what are the way(s) to avoid this occurring as I code in the future?
Well, can't tell the root cause but I was getting the same error in Scala Eclipse editor and I just did "project->clean" and it was gone!
I am trying to make my first JSF application with help of youtube tutorial video. (eclipse/JSF2.0 Dynamic web project). In the first class created, I have to add the below line
#ManagedBean (name = "userRegistration")
But, when I did the same, eclipse shows an error on "name" keyword and giving suggestion to replace it with "value".
#ManagedBean (value = "userRegistration")
But it is not working as expected and threw below error.
/FirstPage.xhtml #10,66 value="#{userRegistration.name}": Target Unreachable, identifier 'userRegistration' resolved to null
Can anyone please help me here?
#ManagedBean(name="userRegistration") is correct. You can avoid (name="userRegistration") part if your java class is UserRegistration. Check if you have imported proper class: java.faces.bean.ManagedBean
Piggy backing on previous answer, I just had this problem as well. Make sure you have the correct import. There are 2 imports that have the #ManagedBean annotation.
javax.annotation.ManagedBean & javax.faces.bean.ManagedBean
javax.annotation.ManagedBean does not have the attribute name, or eager for that matter.
I noticed that if I just annotated my bean class with #annotation that it would import the javax.annotation.ManagedBean class and not the faces one that I wanted.
I am developing a couple of custom widgets that I would like to be able to use with UiBinder. Unfortunately I keep wasting my life away with chasing down the following error:
No class matching "..." in urn:import:...
This seems to be the catch-all exception that is thrown any time there is any error in the class that prevents the GWT compiler from processing it. This includes anything in the class's entire dependency tree.
To save myself and anyone of you who is running into the same issue some time and pain, let's compile a list here of the most unexpected and hard to find causes for this. I'll start with my latest one, which has made me decide to post this here.
I was using a CellList thusly:
private static RelationshipViewerUiBinder uiBinder = GWT.create(RelationshipViewerUiBinder.class);
#UiField(provided=true)
CellList<String> prioritisedDisplay;
public RelationshipViewer() {
prioritisedDisplay = new CellList<>(new TextCell());
initWidget(uiBinder.createAndBindUi(this));
}
note the Java 7 style <> on the CellList. Despite my IDE's protestations to the contrary, it turns out you DO need to explicitly say CellList< String> in that new call, or it wont compile and all you get is the above mentioned error. Thanks by the way, the existance of this question prompted me to scrutinise my code and probably saved me a couple of hours! This fixed it:
private static RelationshipViewerUiBinder uiBinder = GWT.create(RelationshipViewerUiBinder.class);
#UiField(provided=true)
CellList<String> prioritisedDisplay;
public RelationshipViewer() {
prioritisedDisplay = new CellList<String>(new TextCell());
initWidget(uiBinder.createAndBindUi(this));
}
I had written a component that used the GWT JSON functionality, but hadn't imported com.google.gwt.json.JSON into the module.
Thanks to your message here, this was only 2 hours down the drain...
I wrote a helper-class that this widget uses somewhere deep inside its dependency tree.
For this helper-class, I told Eclipse to auto-generate the hashCode() and equals(...) functions. The class contained a field of type double, for which Eclipse generates code that uses Double.doubleToLongBits().
Turns out GWT does not implement this method on its version of Double. But of course, neither does Eclipse detect this as a possible compile-error, nor does it cause any issues in Dev Mode if I use the widget inside the GWT-App's Java code rather than inside UiBinder.
3 hours down the drain... Great... Yay for helpful error messages.
UPDATE:
As of GWT 2.5.0 (RC1) GWT now supports Double.doubleToLongBits() rendering this particular error obsolete, but the general error mechanism of a missing JRE emulation remains and will probably manifest itself in a similarly unhelpful way.
I was trying to use a GwtQuery DragAndDropCellTree in a UiBinder .ui.xml, which was impossible as DragAndDropCellTree has no zero-arg constructor.
See more details
I just started using the Netbeans 7.1 beta and it is calling out errors of a type which I have never seen before. Specifically:
A managed bean with a public field should not declare any scope other than #Dependent.
The fields it is complaining about are public static final. I can understand the restriction on non-static fields, but I can't think of a good reason this would not be allowed for a static field. Unfortunately I use a lot of them since I don't like having constants in my code.
I note that even though I get the red dot in the margin in the editor, the maven-driven build still works and GlassFish still runs my application the way I would expect.
So what is my denoument on this issue? Am I going to have to move my static fields elsewhere or is there another way of handling this?
Quoting the javax.enterprise.inject package javadocs:
If a managed bean has a public field, it must have scope #Dependent.
But I do agree wih #BalusC that if this compiles, Netbeans should report it as Warning (does it?).
Anyway, are those constants really part of the API? I mean, do you access they anywhere else but within their own classes? If not, reduce visibility to private. (If you just need to access the constants from the view you can also create accessors for the private constant). If yes, I would suggest you to move them somewhere else anyway.
Public fields (static or not) aren't proxyable - that's why they can only be dependent scoped. To work around this you obviously can access them through getter methods.