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.
Related
I reloaded on of my test application classes using Instrumentation#redefineClasses(ClassDefinition) method. When I tried adding a new method in the class file and call it from an existing method. It was not happy to for me to do so. But when I called some existing method and other Java Built-In Library methods, it was working fine.
My question is - Is this limitation known/acknowledged by Oracle or Open JDK implementations? I suspect even if you can redefine/retransform your classes using INstrumentation Manifest.MF file - there must be somre sort of limitations to how far you can go with it.
Does anyone have any experience in this thing?
From Instrumentation.html#redefineClasses:
The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. The class file bytes are not checked, verified and installed until after the transformations have been applied, if the resultant bytes are in error this method will throw an exception.
So the answer would be no, it's not possible.
I'm currently debugging some code that looks like this:
if (!clazz.isAssignableFrom(TypeName.class)){
return
}
Using the standard Eclipse debugging tools, I can inspect both classes and see that their names are both
com.packagename.package1.TypeName
I'd like to step into the isAssignableFrom() method that is being used to fail this evaluation when it seems like it should be passing to narrow down what the issue is. I've followed the answers from this question however, when attempting to "Step Into" isAssignableFrom(), Eclipse skips the line and goes right to the return statement, providing me no information about why two of the exact same type somehow aren't assignable from or to one another.
How can I step into this method to see which comparison is failing in an effort to fix the obvious issue with my TypeName class?
You cannot. It's a native method. There is no Java implementation to step into; it's baked into the JVM.
Likely the classes are loaded from different classloaders.
You could check with cls.getClassLoader().hashCode()
I am getting some warnings regarding the accessing static method from a variable over class.
Is there a way to tell errorprone to ignore these warnings? Is error-prone loaded with a set of "bugpatterns"? Is it all of these:
https://github.com/google/error-prone/tree/master/core/src/main/java/com/google/errorprone/bugpatterns
How can I override for instance this to stop complaining:
Warning:(111, 21) java: [StaticAccessedFromInstance] Static method
info should not be accessed from an object instance; instead use
Log.info (see errorprone.info/bugpattern/StaticAccessedFromInstance)
Did you mean 'Log.info( EntityError.class, Gson.asString(this) );'?
I am using Intellij.
Maybe I am mistaken; but I think that "eclipse code cleanup" is able to fix this kind of code problem automatically.
My suggestion would be to rather spend time to understand how such bugs can be easily fixed; versus spending time to suppress the corresponding warning.
According to the errorprone flags documentation, you can switch the check off with:
-Xep:StaticAccessedFromInstance:OFF
However, I agree with Kayaman: you are better off fixing the problem than working to ignore it.
Is it possible to see the return value of a method after the line has been run and before the instruction pointer returns to the calling function?
I am debugging code I can't modify (read: don't want to re-compile a third party library), and sometimes it jumps to code I don't have source to or the return expression has side effects that stop me being able to just run the expression in the Display tab.
Often the return value is used in a compound statement, and so the Variables view will never show me the value (hence wanting to see the result before control returns to the calling function).
UPDATE: I can't use the expression viewer as there are side-effects in the statement.
This feature was added to Eclipse version 4.7 M2 under Eclipse bug 40912.
To use it:
step over the return statement (using "Step Over" or "Step Return")
now the first line in the variable view will show the result of the return statement, as "[statement xxx] returned: "
See Eclipse Project Oxygen (4.7) M2 - New and Noteworthy for details.
Found a really good shortcut for this.
Select the expression which returns the value and press
Ctrl + Shift + D
This will display the value of the return statement. This is really helpful in cases where you can't or don't want to change just for debugging purpose.
Hope this helps.
Note: Have not tested this with third party libraries, but it is working fine for my code.
Tested this on Eclipse Java EE IDE for Web Developers. Version: Juno Service Release 1
That's why I always stick with the following pattern for methods:
MyReturnedType foo() {
MyReturnedType result = null;
// do your stuff, modify the result or not
return result;
}
My rules:
Only one return statement, only at the end of the method (finally allowed after it)
Always have a local called result which holds the returned value, starting from a default.
Naturally, the most trivial getters are exempt.
This is actually a long standing bug in Eclipse, dating back from the very first days of the IDE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=40912
I am curious about to learn the answer to this question also.
In the past, when dealing with 3rd party library like that, what I did is to create a wrapper class or child class that delegate to the parent class and do my debugging in the wrapper/child class. It takes extra work though.
"Now when you return from a method, in the upper method, in the variable view it shows the return value of the previously finished call" [1]
[1] https://coffeeorientedprogramming.wordpress.com/2016/09/23/eclipse-see-return-value-during-debugging/
Tough one. My experience, outside of Eclipse, is that if you might need to see the return value, it is best to assign it to a local variable in the function so that the return statement is a simple return varname; and not return(some * expression || other);. However, that's not dreadfully helpful to you since you say you can't (or don't want to) modify or even recompile the code. So, I don't have a good answer for you - perhaps you need to reconsider your requirement.
Depending on the return statement, you can highlight the expression that is being returned and from the right-click menu, there should be something like "evaluate expression" (I don't have eclipse in front of me now, but it's something like that). It will show you what is going to be returned.
This is a bit far-fetched, but as there doesn't seem to be a simple way:
You could use AspectJ to instrument the JAR with aspects that get hold of the return value of the methods you're interested in. According to Eclipse's documentation, AspectJ programs can be debugged like other programs.
There are two options to weave your classes without recompiling the library :
Post-compile weaving if processing the binary JAR is acceptable;
Load-time weaving, which requires activating a weaving agent in the VM.
See the eclipse documentation (link above) and also the AspectJ Development Environment Guide.
For #Daniel Meyer answer's to work, ensure that 'Show method result after a step operation (if supported by the VM; may be slow)' is checked. The option is accessible via;
Windows> Preferences> Java> Debug> Show method result......
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")