does java support hotswap of annotations?

Question

Afaik, java has many restrictions on hotswap operations such as not allowing change fields or method names. Then what about adding or delete annotations of fields ?

If so, there are still many kinds of annotations besides field annotation such as method annotation, class annotation etc. Does these annotions all support hotswap?

for example, before swap:

class A{
@FieldAnnotation1 int field;
}

after :

class A{
@FieldAnnotation2 int field;
}

Answer 1

AFAIK, Java has many restrictions on hotswap operations such as not allowing change fields or method names.

It depends on how hotswap is implemented;

• These restrictions don't apply if you hotswap code by (say) replacing a servlet.

• For hotswapping in an IDE, the limiting factor is probably the sophistication of the IDE's debugger rather than Java itself.

Then what about adding or delete annotations of fields ?

It is not Java that you need to worry about¹. The Java runtime system will cope with this. As far as Java is concerned, when you "hotswap" a class you are creating a new class. Java doesn't know what the old or new annotations mean, or indeed that the new class is somehow related to the old class. As long as the new annotation can be retrieved from the new class, Java has done its job.

The real issues are:

• Can the IDE cope with it? That depends on the IDE.

• Can the framework that you are using cope with it. It is the framework that "understands" what the annotations mean, and includes the software that deals with them. It would be up to that software to make any adjustments to runtime data structures, behavior and so on if an annotation is changed by hotswapping. Whether it does or does not will depend on the framework.

---

^{1 - The reason I say this is that annotations do not directly affect bytecode execution or the layout of object or stack frames. However, I must admit that I cannot find any clear descriptions of the hotswap or its limitations at the JVMTI level.}