For those interested in hot deployment

[swd847]

I have started an open source project to implement hot replacement of classes in a running JVM, it is hosted here.

It is not ready for production use yet, but I have put up an explanation of how it works here if people are interested.

At the moment it can replace static methods, static fields and annotations, as well as method bodies.

[alin.heyoulin.qq.com]

Excellent work!

[luxspes]

Interesting, I have added some comments to your project page

[asookazian]

I'm still wondering what your solution has over the JRebel 3 solution which currently supports Seam/EJB3 projects in 3.0-M2.  They use javaagent as well.

Perhaps yours is open-source and zeroturnaround's is not, but they do have open-source APIs to develop plugins.

Do you have any marker configuration like the rebel.xml which tells the processor which directories to scan for reloads?

[nickarls]

He just started on it, I'm sure it doesn't have that much over JRebel 3. Either he will produce something useful which can be shared with others or if not, learn a lot from the try. The hot replacement scene is not that crowded...

[swd847]

Arbi Sookazian wrote on Feb 27, 2010 06:31:


I'm still wondering what your solution has over the JRebel 3 solution which currently supports Seam/EJB3 projects in 3.0-M2.  They use javaagent as well.

Perhaps yours is open-source and zeroturnaround's is not, but they do have open-source APIs to develop plugins.

Do you have any marker configuration like the rebel.xml which tells the processor which directories to scan for reloads?

I have never used JRebel, I can't really say one way or another.

The fact that it is open source matters a lot more that you might think, it will open up the possibility of out of the box integration for any open source appserver/framework/whatever, an open source API is not nearly the same thing. Also it means other people can look at it and get ideas and improve it further. 

The marker configuration is largely irrelevant. The hard part is replacing the classes, scanning files and updating the ones that have been changed is pretty much a non issue, at the moment all I have is a seam filter that scans an exploded deployment on every request, I will do a more generic timer based one after I am happy with the core class replacement functionality.

[asookazian]

You both have valid points.  In any event, good luck with fakereplace but be sure to read the JRebel docs, it would be in your best interest...

[asookazian]

And I thought I read somewhere about the modular design of JDK 7 that would solve this hot class reloading problem...

Class path is dead

Reinhold said. --http://www.infoworld.com/d/developer-world/java-get-more-modular-jdk-7-upgrade-919

apparently Sun/Oracle has a patent on the dynamic class reloading: http://www.patentstorm.us/patents/6915511/description.html

has anyone seen this before?

[swd847]

The patent is for a different method (discarding classloaders).

That article did not seem to have anything to do with hot redeployment, although the new invokedynamic instruction could simplify the implementation of fakereplace somewhat.

Incidentally I think the name is terrible, but I couldn't think of a better one. I wanted to call it cheetah or jcheetah but they are already taken.

[nickarls]

jPlacebo? jBaitNSwitch? ;-)

[asookazian]

I would replace 'fakereplace' with something like 'JReplace' or 'JReload' or 'QuickSync' or 'ReClassify', etc...

[luxspes]

Maybe the project name should be DynamicInvocationHandler? The idea of the catch all  __REDEFINED_STATIC_METHOD_(int methodNo, Object[] parameters) method seems very similar to java.lang.reflect.InvocationHandler.invoke method

[luxspes]

Mmmm, I wonder if the code Groovy.invokeMethod could be somehow reused/repurposed/used-as-guidance to implement the I control all method calls in a single place behavior needed by the fakereplace

[swd847]

One of the main design goals is to be as unobtrusive as possible, and to use a dynamic language approach would be to invasive, and carry a large performance penalty. The idea is that if you do not replace any classes the only difference between what you wrote and what is being run is that reflection calls are handled by a different class (this alone is problematic enough due to permission issues).

Even simply adding a method can have an impact on running code, as it can change an objects automatically generated serialVersionUid and break serialization.

There are other approaches to adding methods that the one I have taken. It is possible to take an instance method and change it to a static method on a new class, however you then run into permission problems accessing private members on the original class. These can be fixed by modifying everything as it is loaded into the JVM to remove the private marker, however then you have to emulate it again in the instrumented reflection API.

The actual recompiling of the bytecode is the easy bit, the hard part is making sure that what you end up with exactly matches the behavior of a system running without fakereplace.

Stuart

[asookazian]

new article on 5 JRebel features you couldn't do in the JVM: http://www.theserverside.com/news/thread.tss?thread_id=59573