'volatile' in method signature? [duplicate]

Answer 1

This answer has already been covered in the question Why make a method volatile in java? But here's some more information.

When you overload methods (possibly only generic methods in the superclass), the method is marked as being a "bridge method". From java.lang.reflect.Modifier:

static final int BRIDGE    = 0x00000040;

Unfortunately, this is the same bit that is used to mark fields as being volatile:

public static final int VOLATILE         = 0x00000040;

If you print the modifiers on that method you will see something like:

public volatile

This is a limitation in the Modifiers.toString(int) method that doesn't know if it is a field or method.

public static String toString(int mod) {
    StringBuffer sb = new StringBuffer();
    ...
    if ((mod & VOLATILE) != 0)  sb.append("volatile ");
    // no mention of BRIDGE here
    ...
    return sb.toString().substring(0, len-1);
}

Answer 2

The modifier mask for fields and methods is similar but not exactly the same. The decompiler is most likely using the toString method here

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/reflect/Modifier.java

but what it doesn't do is handle all bits

// Bits not (yet) exposed in the public API either because they
// have different meanings for fields and methods and there is no
// way to distinguish between the two in this class, or because
// they are not Java programming language keywords

What its doesn't handle is the bits which can mean synthetic and bridge which identify compiler generated code.

If volatile means anything at all here, it could mean don't remove the method even though it doesn't do anything.

Answer 3

It doesn't mean anything. It is a bug in the decompiler. End of story.

(The bug is probably related to the fact that certain flag bits used in the class file format are "overloaded", meaning different things in the context of a class, field or method. I also vaguely recall that there have been some "new uses" in recent JVM spec revisions.)

Answer 4

It is a bug in your decompiler.

volatile is only a valid modifier for a field.

I recommend you to read this aricle.