With AOP I did not see this problem solved. I guess this was also not the intention of the inventer. But with HotSwap I would like to have this problem solved. So coming to the topic. I dont think AOP and hotswap should be intermingeled. Hotswapping functionality is required for JAVA in the business environment. If AOP utilizes this hotswapping functionaly it is welcome.

I simply think that HotSwap and JVMTI is a spec that should be deprecated and that we should focus on:

1. What do we want to do, the problem that has to be adressed?
2. What is the High-Level (not bytecode level) API can help us getting there (could be something similar to or an extention to the one we have in JRockit).

I would die to get inter-type declarations (also called introductions, e.g. redefinition of the class) with support for Schema Change into Mustang.

We want to build a web app, incrementally, while it runs, Ruby on Rails style. What do we need to achieve this, and how will a high-level VM API help?

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.

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 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.

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?