We Keep Coding

Advantage of #SuppressWarnings annotation

#SuppressWarnings annotation is for cleaner code or by adding it is there any performance gain or any advantage ?
or can we reduce compile time by doing so.

The #SuppressWarnings annotation type allows Java programmers to disable compilation warnings for a certain part of a program (type, field, method, parameter, constructor, and local variable). Normally warnings are good. However in some cases they would be inappropriate and annoying. So programmers can choose to tell the compiler ignoring such warnings if needed.
There is no relation with performance.
The developer who wrote the code knew that it was always going to be safe, decided to use #SuppressWarnings("unchecked") to suppress the warning at compilation.
As mentioned by others, it is just a trust between the developer and code written.
more info here and here

There is no performance gain, only when compiling, compiler will or will not write a waring. However after compilation, there is no difference whatsoever.

It does not make your code cleaner or improve the performance. It just helps you to concentrate your attention on potentially dangerous code. If you have a list of 130 warnings you will soon stop to read them.
Most warnings represents bad programming practices or potencial problems that the compiler is not able to solve. A finished program should, ideally, compile with no warnings. This way, when you modify it and a new warning appears you can decide what to do.
For example:
Unreachable code. What was I thinking here
Lib ZZZ is deprecated. Should I upgrade to the new one? Can I continue with this for now?
Add type arguments to list... ups, I should be using generics

SuppressWarnings annotation is just to suppress warnings that you know are sure to occur and you don't care about it. Its just helps you to have a cleaner inspection, suppressing warnings you expect to see. No performance gain.

Sonar rule - Reorder the modifiers for interface default methods

I just started using Sonar and I have a project with JDK 8. The only problem I've got so far is:
Reorder the modifiers to comply with the Java Language Specification.
This is happening for my default methods in interfaces, like
default boolean isValid([params here]) {
/*method body here*/
}
I know that this is really a minor issue, but I don't want to disable any rule, so how do you fix it?
Thank you very much!
p.s. I haven't found anything on Google, I know what this rule means(I have read its description), but I cannot figure out how to deal with default keyword.
Update: It looks like a bug, I have reported it here, https://jira.codehaus.org/browse/SONARJAVA-590
Update 2: It seems it's already fixed and it will be available in 2.4 version.

The method declaration syntax for interfaces is covered in the JLS, section 9.4.
Briefly, method modifiers must precede the method header, which includes the method's return type. Your declaration has one method modifier default and its return type is boolean so there is no other possible arrangement in this declaration other than
default boolean isValid(/*parameters*/) { /*body*/ }
Therefore I think this must be a bug in Sonar.

Hi Thanks for your feedback.
You can have a look at the source code of the check : ModifiersOrderCheck(link to last commit at time of writing)
And you will see that the default modifier is not checked as this rule was not updated since the support of Java 8 in the sonar-java-plugin.
So it is indeed a bug, but it has to be reported on the java plugin project and not on the Mojo's sonar maven plugin. I created the correct ticket: https://jira.codehaus.org/browse/SONARJAVA-590 Feel free to vote for it.

Explore an Array in GWT without knowing its type

I am building a generic visualizer of objects with GWT. For this, I am using the reflection capabilities offered by gwt-ent. With it I can explore methods and fields and that's enough for classes. One problem I still have is that gwt-ent does not allow me to explore arrays. It gives me the type of its components, but not a get() or a set() method, as java.lang.reflection.Array does.
So I have used the native java.lang.reflection.Array, which curiously works when in debug mode (how is that possible?), but when I go into production mode the compiler complains.
I have tried some tricks, for instance by converting the array to an ArrayList with java.utils.Array.asList(T... a) but there's not way for making it work. I have seen a similar problem here. In that case one of the suggestion was to import the JSNI method provided byt com.google.gwt.lang.Array.createFrom(..), but I can see in the source code that this class unfortunately has a set() method but no get() method !
The question is: do you see any way for accessing an element of an array without knowing the type of the array in advance?

Reflection is not supported in GWT compiled. It can work in dev-mode because most of the code when debugging is run in JVM instead of browser.
I suggest, to modify the gwt-ent generator to match your requirements and send a patch to the author with your contribution, or maybe change gwt-ent by other 3party library like gwt-reflector.
Another interesting gwt reflection project I've found is gwt-processor it seems not to use generators.

Automatically add "this." to instance variables

We have started to implement checkstyle as a way to provide a consistent code style across developers. One of the checks requires that all instance variables be references using "this.". I have not been in the habit of using "this.", and so have thousands of instances that need to be fixed.
Is there a tool or IntelliJ plugin that can just run through and add the appropriate code?

One of the checks requires that all instance variables be referenced using "this."
So 'checkstyle' is mistaken.
I have not been in the habit of using "this."
Quite right. It's redundant. Good for you.
so have thousands of instances that need to be fixed.
So you are mistaken.
You don't have any instances that 'need to be fixed'.
Don't do it. It's redundant. Don't perform redundant work. Nobody wants to pay for it, and why should they? Modify your checkstyle configuration so as not to require it. Don't let tools tell you how to spend money, and don't be fooled that a 'consistent code style across developers' is essential to delivering a working product. It isn't, as long as the code is legible and maintainable. I have seen more time and money wasted on this issue than I care to think about.

In eclipse:
Window - Preferences - Java - Editor - Save actions - Configure... - Member access -
Here you check the "Use this" checkboxes.
On every save on code it will make the correction.
I just found this page.
It is a never too late to read for those who want to use eclipse efficiently. I guess there will be something similar to Netbeans and others as well.

One of the checks requires that all instance variables be references using "this."
IMO, the best solution is to raise this with the rest of the development team, and get agreement to turn that stupid check off. If adding redundant this keywords improves readability then you have to doubt the Java skills of the people reading the code.
If they pushed back, I'd be tempted to register my distaste thusly:
public class SomeClass {
private String thisName;
public String getName() {
return this.thisName;
}
public void setName(String notThisName) {
this.thisName = notThisName;
}
// and so on
}

Java: complete list of #SuppressWarnings(...) parameters (in Netbeans)?

Netbeans provides a lot of custom "hints", which are like warnings, only that most of them can't be suppressed (just disabled IDE-globally).
But now I looking at code which uses
#SuppressWarnings("element-type-mismatch")
to suppress a hint/warning which is called "suspicious method call" (such as remove(...) for a collection with a "wrong" type).
Well, I would never come to the idea to suppress a hint named "suspicious method call" with a SuppressWarnings-parameter called "element-type-mismatch", but apparently, it works.
So, is there a "magic list" of such parameters?
How, for instance, do I suppress the hint/warning "return of collection field"?
NOTE: for this similar question, "element-type-mismatch" is not listed.

After a brief look at the NB-sourcecode, I found these in some of the java.hint -classes:
#Hint(category="bitwise_operations", suppressWarnings="IncompatibleBitwiseMaskOperation")
#Hint(category="initialization", suppressWarnings="LeakingThisInConstructor")
#Hint(category="logging", suppressWarnings={"NonConstantLogger"}) //NOI18N
#Hint(category="logging", suppressWarnings={"ClassWithMultipleLoggers"}) //NOI18N
#Hint(category="logging", suppressWarnings={"ClassWithoutLogger"}, enabled=false) //NOI18N
#Hint(category="code_maturity", suppressWarnings="UseOfObsoleteCollectionType")
#Hint(category="initialization", suppressWarnings="OverridableMethodCallInConstructor")
#Hint(category="bitwise_operations", suppressWarnings="PointlessBitwiseExpression")
#Hint(category="code_maturity", suppressWarnings="CallToThreadDumpStack")
#Hint(category="bitwise_operations", suppressWarnings="ShiftOutOfRange")
#Hint(category="initialization", suppressWarnings="StaticNonFinalUsedInInitialization")
#Hint(category="code_maturity", enabled = false, suppressWarnings="UseOfSystemOutOrSystemErr")
#Hint(category="code_maturity", suppressWarnings="CallToPrintStackTrace")
Apparently, not all IDE-hints that are displayed as warnings are made suppressable...
Don't know why though, 'cause the AbstractHint class wich many of them extends easily provides this ability...
These are just the suppress-names though, so to find the mapping to the names of the warnings they represent, a deeper dig in the source is needed.

The documentation says:
Compiler vendors should document the warning names they support in conjunction with this annotation type. They are encouraged to cooperate to ensure that the same names work across multiple compilers.
Since NetBeans is using javac I think, here is a list.
See also this question.
If you are using another compiler, or some compiler plugin, search for its documentation.

Well the list is hard to find. Did find the sources of the hint classes of Netbeans.
So the 'list' is here. (also look at the sub packages; e.g. jdk and perf)
All classes can be supressed by using its camel cases name like:
// org.netbeans.modules.java.hints.jdk.UnnecessaryBoxing.java
#SuppressWarnings("UnnecessaryBoxing")