Description Maxim Moldenhauer 2013-01-28 11:32:25 EST

According to bug 120375, hot code replacement should be working with LTW. However, I've debugged the code to notice that it never even tries to reweave the class in question.

In the WeavingAdaptor.weaveClass method it does a call to the couldWeave method to decide whether to retrieve the woven bytes which does the following:
return !generatedClasses.containsKey(name) && shouldWeaveName(name);

However, the generatedClasses map does in fact contain a key of the same name which was added during the initial load of the class before hot code replacement.

As a quick test, I modified ClassPreProcessorAgentAdapter.transform to call a new method on Aj.java called preProcessReweave when we're going through the reweave path instead of calling the normal preProcess.

preProcessReweave does the same thing as preProcess except that it calls
weavingAdaptor.getGeneratedClasses().remove(className.replace('/', '.')); right before calling weavingAdaptor.weaveClass. (I had to add a getter for the generatedClasses map.) This allows the couldWeave method to return true and then everything works as expected and hot code replacement works.

I'm curious why I had to do this and how this ever worked. Could it be that something was supposed to be calling ClassLoaderWeavingAdaptor.flushGeneratedClasses?

Any help is greatly appreciated. Thanks!