Semergence

Seth Ladd’s blog about Ruby on Rails and crunching data.

Automatic Java Class Reloading

with 5 comments

I just saw JavaRebel from ZeroTurnaround.com, which promises to “reload changes to Java classes on-the-fly without redeploy or restart including new methods and fields. It is a generic solution that works for standalone Java applications as well as application servers.”

This is the dream within a dream for Java development. One of the main reasons I moved to Ruby on Rails for web development is due to the much faster development cycle of Change then Test. Back in my Java days, it was Change, Compile, Wait 5 minutes to deploy, Bounce the server, then Test.

If JavaRebel can do what it says (and I haven’t tried it) then all you Java developers out there might suddenly get a lot more productive. If you’ve used this tool, drop me a comment.

Written by sethladd

October 11, 2007 at 8:32 am

Posted in Java

5 Responses to 'Automatic Java Class Reloading'

Subscribe to comments with RSS or TrackBack to 'Automatic Java Class Reloading'.

  1. Basically, I have seen most of the development on JavaRebel, considering the people next door to me are developing it :)

    We at Webmedia have used JavaRebel extensively in most of our projects, for over half a year now.

    I can not recommend it enough, and yes, it does exactly what it is supposed to do.

    Changing stuff in Eclipse is like this:
    Modify code, save => eclipse automatically builds.
    Hit F5 in browser, your view instantly refreshes, no redeployment.

    This accounts for about 80% of the cases, and this percentage is increasing.

    It works flawlessly on Windows and Linux, also from what I heard, MacOS JVM has no problems with it either :)

    Dmitri

    11 Oct 07 at 11:06 am

  2. This really is not new, application servers have been doing doing this for years now (Tomcat, Websphere, even JRun). As far as a development environment, the Java debugger can alter classes in memory at runtime - in fact runtime AOP uses a similar technique.

    Take the IDE Eclipse for example, in a debug session you can alter the code while the application* is running. In certain circumstances, the IDE will detect this and rollback to the previous breakpoint allowing you to reiterate that troublesome loop using the new code.

    *Don’t forget a Java web-app server is itself a Java app. You can use change the code in memory there too.

    Anonymous

    11 Oct 07 at 11:18 am

  3. To Anonymous

    You are talking about Java HotSwap. In debug sessions you can modify method bodies. You can’t do anything else (create/delete/change methods, fields, classes). This has nothing to do with application servers. Application servers have to support the JPDA and you get HotSwap basically for free.

    JavaRebel does not require to suspend any threads or be in debug mode and you can change almost anything. See JavaRebel features for more details:

    http://www.zeroturnaround.com/javarebel/features/

    Toomas Römer

    12 Oct 07 at 2:47 am

  4. Yet nothing has even come close to the scope at which Javarebel is capable of it, outside specific frameworks.

    I mean, sure hotswap has been introduced for a while now… Or other methods.

    The catch is, please do compare the amount of limitaitons Javarebel has and the amount of limitations other methods have.
    You will find the answers if you do your homework right (and read the original article on theserverside fully).

    DD

    12 Oct 07 at 4:46 am

  5. [...] 18, 2007 @ 12:19 am · Filed under Uncategorized Spoke to Seth and he talked about ZeroTurnaround.com > JavaRebel This looks very promising. At my new gig, [...]

Leave a Reply