I agree that it does not make any sence to use HotSwap for dynamic bytecode instrumentation. However it still would come handy for changing code when debugging. Current HotSwap implementation can survive very limited subset of changes that one could introduce into the class.

The requests for Hotswap improvements are about speeding up development, not about bytecode instrumentation. For example, when I'm debugging a web application in my IDE, I want to be able to change a class and have all of it's instances updated, too, without my having to restart the server (which can take minutes in some applications). If I make an incompatible change, I want the JVM to do it's best to update existing instances. It doesn't have to be perfect as it's development time-only.

Debugging is not only (potential) use-case for HotSwap since it is now part of JVMTI (redefineClass(..) does not require -Xdebug). When Java 5 is becoming more and more popular I think that the usage of Java Agents will raise and some agents (vendors) will for sure use redefineClass().

I understand that people want this badly, I am just worried that it will generate more problems than it solves and I think that we are heading down the wrong direction in JVMTI (in which there are parts that I think should be deprecated).

As soon as there are more than one single active agent then correctness and behavior of the application can not be garantueed. You might have more than one agent in development situations as well...

Besides, I do not see why patching code at runtime could not be done at a higher level than in the bytecode layer...(even when doing debugging). It has to de defined though.

Hi Jonas,

you make a valid point about the multiple agents, but I don't see how JRockit's native AOP support would make Java development more interactive during development. I rarely use AOP, I just want the running JVM to use newly compiled classes without having to restart it. I also don't want to setup anything for this, I just want to press a 'hotswap' button and check the new version. Do you have a solution that would allow this without JVMTI redefineClass()?

Maybe a solution for the multiple agents problem can be found, without throwing away hotswap?

I am not saying that the end user should have to care at all which impl technique is used. You should just have to press 'debug' and then change the classes as you want. (And don't get me wrong, I want the same feature myself).

I just want drive the discussions away from bytecode munging (and that is what the debug agents are doing) to a more high-level, predictable, well-defined and performant API.

The work we have done in JRockit tries to have a wider scope than just AOP. We basically want to define an API rich enough for the user to not have to do bytecode manipulation (at least cover in 95% of the use-cases).

There has been a lot of discussions on the JVMTI expert group on how to take the spec further, and it seems that it in some ways is heading down a dead end road.

Jonas,

I look at it from a development point of view. I am totally with Geert, no setups of anything. Why is the JVMTI road a dead end? And why isn't yours?