Get name of a field

Unfortunately, there is no way to do what you wish. Why?

In an era where we are still trying to prove that Java is not slow, storing metadata of where or how an object was constructed would have a large overhead, and since it has a very minimal range of use, it does not exist. Not only that: there are a bunch of technical reasons as well.

One reason is because of how the JVM is implemented. The specification for the Java class file format can be found here. It’s quite a mouthful, but it is very informative.

As I said previously, an object can be constructed from anywhere, even situations where objects do not have names. Only objects defined as class members have names (for the obvious reason of access): objects constructed in methods do not. The JVM has a local variable table with a maximum of 65535 entries. These are loaded unto the stack and stored into the table via the *load and *store opcodes.

In other words, a class like

public class Test {
int class_member = 42;

   public Test() {
      int my_local_field = 42;
   }
}

gets compiled into

public class Test extends java.lang.Object
  SourceFile: "Test.java"
  minor version: 0
  major version: 50
  Constant pool:
  --snip--

{
int class_member;

public Test();
  Code:
   Stack=2, Locals=2, Args_size=1
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   bipush  42
   7:   putfield        #2; //Field class_member:I
   10:  bipush  42
   12:  istore_1
   13:  return
  LineNumberTable:
   --snip--    
}

There, you can see a clear example from javap -v Test that while the name class_memberis preserved, the my_local_field has been abstracted to index 1 in the local variable table (0 is reserved for this).

This in itself would be a pain for debuggers and such, so a set of attributes (think metadata for class files) was designed. These include the LocalVariableTable, LineNumberTable, and LocalVariableTypeTable. These attributes are useful for stacktraces (LineNumberTable), and debuggers (LocalVariableTable and LocalVariableTypeTable). However, these are completely optional to include in files, and there is no guarantee that they are:

The LineNumberTable attribute is an optional variable-length attribute
in the attributes table

The same holds for the rest of them.

Additionally, most compilers do not produce anything but the LineNumberTable by default, so you’d be out of luck even if it was possible.

Basically, it would be quite frustrating for developers to have a getFieldName(object) (which wouldn’t be possible in the first place for local variables), and only have it work when those attributes are present.

So you are stuck for the foreseeable future with using getField with Strings. Shameless plug: IntelliJ seems to handle refactors with reflection quite well: having written Minecraft mods as well I know the feeling, and can say that work in refactoring is significantly reduces by IntelliJ. But the same is probably true for most modern IDEs: I’m sure the big players, Eclipse, Netbeans et al. have well-implemented refactoring systems in place.