I run checkstyle on my Java code and get this error:
variable access definition in wrong order
Can somebody tell me what that means?
Could it be that you have declaration order configured in CheckStyle? Take a look at
http://checkstyle.sourceforge.net/config_coding.html#DeclarationOrder
In that link, you will notice that it says ...
*According to Code Conventions for the Java Programming Language , the parts of a class or interface declaration should appear in the following order:
Class (static) variables.
First the public class variables,
then the protected,
then package level (no access modifier), and
then the private.
Instance variables.
First the public class variables,
then the protected,
then package level (no access modifier), and
then the private Constructors Methods*
Maybe it is a little late for answering this question but in my case i had some thing like that:
public final class ClassA{
private ClassA() {
}
private static Logger LOG = LoggerFactory.getLogger(ClassA.class);
}
and after i changed the order to:
public final class ClassA{
private static Logger LOG = LoggerFactory.getLogger(ClassA.class);
private ClassA() {
}
}
my problem solved.
I'm guessing you have something like static public int. Normally, that would be written as public static int.
Related
I created the following JNA structure which works in my project context :
#FieldOrder({ "string", "stringSize" })
public static class stringStruct extends Structure {
public static class ByReference extends stringStruct implements Structure.ByReference {
}
public static class ByValue extends stringStruct implements Structure.ByValue {
}
public String string;
public int stringSize;
}
I launched sonarQube analysis on my code and sonarQube raises the following error:
"Make stringSize a static final constant or non-public and provide accessors if needed."
That's weird because I have two fields in my structure and only one them raises such an issue.
Anyway, if I've correctly understood, regarding this issue I should do something like that to fix the issue on stringSize field :
#FieldOrder({ "string", "stringSize" })
public static class stringStruct extends Structure {
public static class ByReference extends stringStruct implements Structure.ByReference {
}
public static class ByValue extends stringStruct implements Structure.ByValue {
}
public String string;
private int stringSize;
public int getStringSize() {
return stringSize;
}
public void setStringSize(int stringSize) {
this.stringSize = stringSize;
}
}
But This not the way JNA works, isn't it?
Thus can I assume that there is something wrong with the sonarQube criteria I'm using? And not on my implementation.
JNA relies on the public modifier for class fields of structures, which are accessed via reflection.
Accessor methods are generally not used, except in convenience, e.g., if you have a byte[] or char[] field that's intended to be text, you might add a getFooString() accessor method to make fetching that String easier.
So yes, you'll have to ignore and/or suppress Sonar warnings on those, as they are typically non-compliant. In general, JNA mappings also tend to preserve the case of the field names as well, which Sonar also complains goes against standards! This is not so much a flaw in Sonar -- these are generally good rules for your other code. It's just not the way JNA works.
I try to put all my JNA code in its own package for a few reasons:
it makes it easier to exclude the package from certain CI tools like Sonar
when migrating to the Java Module System (JPMS), you will need to open the package(s) with JNA structures to com.sun.jna for the Structure class to see them with reflection.
it makes it easier for you to go through your code later and find things to contribute to the user mappings in the JNA project and give back to the community!
This question already has answers here:
Why is an anonymous inner class containing nothing generated from this code?
(5 answers)
Closed 7 years ago.
In the below code :
class EnclosingClass
{
public static class BiNode extends Sub.IBiLink { }
private static class Sub
{
private static class IBiLink
{
}
}
}
On compiling along with other .class files, I also see a file named "EnclosingClass$1.class" .Why has this been automatically created? Whats going on?
First have a look at the class access and propery modifier table from the JVM specifications.
Notice the ACC_SYNTHETIC flag which interpretation specify that it is not present in the source code (in simplier words, it will be added when the class is generated by the compiler).
Let's have a look at the bytecode of EnclosingClass$1.class (note that I will paste only the part that matter).
javap -v EnclosingClass$1.class
produce the following result
Classfile /C:/Users/jfrancoiss/Desktop/Nouveau dossier/EnclosingClass$1.class
Last modified 2015-03-31; size 190 bytes
MD5 checksum 5875440f1e7f5ea9a519d02fbec6dc8f
Compiled from "EnclosingClass.java"
class EnclosingClass$1
minor version: 0
major version: 52
flags: ACC_SUPER, ACC_SYNTHETIC
Notice that the access flags of the class contains ACC_SYNTHETIC.
The ACC_SYNTHETIC flag indicates that this class or interface was
generated by a compiler and does not appear in source code.
An other option to make sure the generated class is synthetic is to compile as
javac -XD-printflat EnclosingClass.java
which would produce
/*synthetic*/ class EnclosingClass$1 {
}
Great, but why generate a synthetic class ?
The Java reflection tutorial can help us understand this. Have a look at the comments in the SyntheticConstructor class
public class SyntheticConstructor {
private SyntheticConstructor() {}
class Inner {
// Compiler will generate a synthetic constructor since
// SyntheticConstructor() is private.
Inner() { new SyntheticConstructor(); }
}
}
So according on the comment, the synthetic class EnclosingClass$1.class was created because IBiLink was private.
Once again, the java reflection tutorial specify at this point
Since the inner class's constructor references the private constructor
of the enclosing class, the compiler must generate a package-private
constructor.
In our case, we do not see explicitely any constructor call, but we have this line
public static class BiNode extends Sub.IBiLink { }
Let's try compiling this code and see what happen
class EnclosingClass
{
//public static class BiNode extends Sub.IBiLink { }
private static class Sub
{
private static class IBiLink
{
}
}
}
No EnclosingClass$1.class generated.
More details noticed when debugging
Change
private static class IBiLink
to
protected static class IBiLink
notice that when compiling, EnclosingClass$1.class is not created.
why does protecting the class did not generate a synthetic class ?
Simply because when protecting the class, you implicitely get access to each of the super classes.
Why don't eclipse compiler generate a synthetic class ?
Eclipse use it built-in compiler, which you can configure it severity level.
By default, Access to a non-accessible member of an enclosing type is set to ignore as you can see on this image.
Change it for example to warning and you will get the following message.
which let me believe that eclipse, altought does not create an other class, will emulate it to simulate the synthetic member.
When decompiling a specific jar using java decompiler (http://java.decompiler.free.fr/) I got some strange code I cannot identify what is. can someone help me? the code is something like:
Foo.access$004(Foo.this);
or this
Bar.access$006(Bar.this);
or else
Baz.access$102(Baz.this, true)
What are these methods access$004, access$006 and access$102?
Synthetic methods like this get created to support acessing private methods of inner classes. Since inner classes were not part of the initial jvm version, the access modifiers could not really handle this case. The solution was to create additional package-visible methods that delegate to the private implementation.
public class Example {
private static class Inner {
private void innerMethod() { ... }
}
public void test() {
Inner inner = ...
inner.innerMethod():
}
}
The compile would create a new method of the Inner class like this:
static void access$000(Inner inner) {
inner.innerMethod();
}
And replace the call in the test method like this:
Inner.access$000(inner);
The static access$000 is package visible and so accessible from the outer class, and being inside the same Inner class it can delegate to the private innerMethod.
These are auto-generated methods which are created by the compiler in some cases (for example when accessing private fields of another class directly, e.g., in case of nested classes).
See also What is the meaning of "static synthetic"? and Synthetic Class in Java.
If you get the relevant .class file (run jar through unzip), and run the .class file through JAD
JAD MyClass.class
then you may find that the output JAD file has decompiled that particular line in a more meaningful way, e.g.
Baz.access$102(Baz.this, true)
shows up in the JAD output as simply
myMemberVaiable = true
where myMemberVaiable is a member of class Baz that you will recognise.
I have code where a variable name is identical to the class name. I.e.:
class Foo {
static public void main(String[] args) {
Integer Foo;
Foo.main(args);
}
}
How can I call the main-method without renaming the variable or the class?
If it's not in the default package you could refer to it via the package name also, e.g.:
packagename.Foo.main(args);
or you can simply refer to main without the class name, e.g.:
main(args);
If class Foo is in a package, you could use the fully qualified name:
my.package.Foo.main(args);
You could also rename variable Foo; it's bad Java style to capitalize variable names. Finally, why would you want to call main from main like that? It's going to overflow the stack very quickly.
Since Integer does not have a main(...) method, this is not a problem.
More generally speaking, if you need to disambiguate, use the full package name.
use the full package name, it works.
package my.pck;
class Foo {
static public void main(String[] args) {
Integer Foo;
my.pck.Foo.main(new String[] { "arg" });
}
}
But why would you want to call main from main like that? its creating infinite loop.
I have code where a variable name is identical to the class name
Why? The simple answer is "don't". The convention is that class names start with a capital and member variable names don't, which takes care of it completely.
I have a strange problem i don't know if i miss something. Here is my code
public interface Book{
}
public class MyBook implements Book
{
}
public static void main(String[] args)
{
Book b = new MyBook(); // compiler error: Type mismatch ....
}
Can somebody explains to me is this really a compiler error or just my eclipse is acting weird?
Thanks,
Your main method is not in a class, try putting it inside a class.
Also make sure to have only one public class per Java file.
I think after implementation of interface you can make object of class that implemented interface so make the object of class "MyBook"
Sorry, there is another interface of exact same name that is in the imported statement that is causing the problem. Thanks.