Jevgeni Kabanov

Java Rebel Support
+ Follow
since Jul 22, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jevgeni Kabanov

Congratulations! Actually we'd need the winners' email adresses and names.
Implementation changes are definitely supported. JavaRebel also supports changes to EJB interfaces in containers that use proxies (e.g. JBoss), though it doesn't always work perfectly.
Oh, and I wrote a blog post about the multiclassloader trick some time ago:
http://blog.araneaframework.org/2006/11/21/zero-turn-around-in-java/
Grails uses the same approach as Tapestry 5, RIFE and some others. It involves wrapping a class (or classes) in a distinct classloader and when the class changes dropping the old classloader, creating a new one and loading the class anew.

The problem with this solution (or one of the problems) is that with the old classloader and the old class you also have to drop all existing instances of the class. In some cases (like when class is serializable or it is a singleton and has no identifying state) instances are easy to reconstruct. In general this is not the case.

Grails wraps all controllers and some singleton components into this classloader, but this does not apply to the rest of the code like utility classes and etc. Also you may get ClassCastExceptions unless you use the "var" notation.

JavaRebel on the other hand preserves all existing instances as is, reloads all classes indiscriminately and does not create any new classloaders. We actually discussed getting JavaRebel to work with Groovy with Groovy developers since it also works e.g. for Scala. At the moment it waits for a fix for call site caching feature of the Groovy compiler.

Originally posted by Jaikiran Pai:
Normally, in a redeployment process, the old instances are discarded, but how is it in JavaRebel?



The whole point of JavaRebel is that all the existing instances are preserved, but their code is updated. So in your case the object in the session will be preserved, but it will now be missing the method "sayHello()" (and will have any methods that you added).

Note that we also allow adding new fields without redeploying. In that case they will not be initialized in the existing instances, so you may get some NPEs until you recreate them.
[ August 13, 2008: Message edited by: Jevgeni Kabanov ]
JavaRebel neither introduces new classloader nor changes the classloader hierarchy in any other way. The classes will be loaded in the same classloader as usual (including changed ones).
[ August 12, 2008: Message edited by: Jevgeni Kabanov ]
Download includes a trial license valid for 21 days. Just try it out.
No, plugin isn't free to use. You can see the terms and pricing here:
http://sales.zeroturnaround.com/

Usual price for a license is $149, though at the moment there's a discount for personal licenses to $49.
JavaRebel is a product of ZeroTurnaround, which is a trademark of AS Webmedia, the largest custom software development in the Baltic states. No connection to Sun whatsoever. I am indeed the lead developer of the software.
Only a personal software license. But if you like it, we can print out the manual and the articles and send that to you as well I wonder if printing the screencast frame-by-frame you can play it as a paper animation?
JavaRebel doesn't log specially much, only issues some statements to console. If you want to see a detailed log you can add "-Drebel.log=true" to the JVM command line. This will create a JavaRebel.log file in the same directory that javarebel.jar is in.
We just released a plugin that reloads Spring configuration:
http://www.zeroturnaround.com/news/develop-spring-applications-without-redeploying/

At the moment there are no plans to provide same level support for Hibernate, as it is much much harder to do than for Spring (which wasn't easy either).
Sure, there's a small post on developing standalone (Swing) with a short screencast:
http://www.zeroturnaround.com/news/screencast-developing-swing-with-javarebel/
You can see a comparison between JavaRebel and HotSwap here:
http://www.zeroturnaround.com/javarebel/features/

The main difference is that JavaRebel supports class schema changes and doesn't need a debugging session.

As for the hot-deployment, the main difference is that JavaRebel preserves all of the state (both session and application) and reloads changes nearly instantly. Hot-deployment will reinitialize the whole application and usually take a lot of time.
What do you mean under clustered JVMs? And note that it's a development tool.