Diving in

You downloaded a shiny new JRebel and it doesn’t work? You’re in the right place. We will walk through the typical problems and tell you exactly how to get it up and running.

First things first. Most of the solutions in this guide assume that you have enabled JRebel logging. To do this, you can either add -Drebel.log=true to the JVM command line of your server or application or in the plugin settings page of your IDE. The default jrebel.log file location is the {user.home}/.jrebel directory. If JRebel support asks you for the JRebel log file, more specific instructions can be found here. Now we are ready to walk through those common issues.

The server or application does not start

You followed the installation instructions to the letter, but for some reason your server doesn’t want to start with JRebel. Here are some things to check out:

  • If the following message is shown:
    Error opening zip file: /jrebel/jrebel.jar<br>Error occurred during initialization of VM agent library failed to init: instrument
  • It means that the path following the -javaagent: is incorrect. Find the full path to the installed jrebel.jar and paste that instead.
  • If you are using Java 1.4 OR an IBM JDK, make sure that you generated the jrebel-bootstrap.jar with the same version of JVM and same version of JRebel that the Server is started with. To regenerate the jrebel-bootstrap.jar run java -jar jrebel.jar, making sure that java -version is correct.
  • If the server/applications fails startup with an OutOfMemoryError, try adding more memory to the heap. If “permgen space” is mentioned add -XX:MaxPermSize=128M or more to the JVM command line parameters (or increase the number if already present). Otherwise add -Xmx256m or increase the number if already present. Note that sometimes when running out of memory or permgen space the JVM will crash altogether.

No JRebel banner in the console

Every time JRebel agent starts up you should see the following banner in the console:

  JRebel 5.0.1 (201207181843)
  (c) Copyright ZeroTurnaround OU, Estonia, Tartu.

Yep, proudly made in Tartu, where the temperature just last year fell to -30C (that’s -22F for our imperial friends). But we’re digressing, if you don’t see that banner, something is wrong and you have these options:

  • Check that the -javaagent:jrebel.jar actually gets to the JVM command line. If you changed %JAVA_OPTS% or %JAVA_OPTIONS% to include it (that’s what most of the scripts included in the installation instructions do) then try adding echo %JAVA_OPTS% in the server startup script right before it’s launched.
  • For some servers (like WebSphere or GlassFish) it’s quite possible that the banner is shown, but buried in one of the console output logs. Check those logs, or even easier check the jrebel.log.


This message usually means that the 2 weeks granted to evaluate JRebel are over. However, sometimes this is shown even if you think you have a valid license. In that case:

  • Check that there is a jrebel.lic in {user.home}/.jrebel directory.
  • To check that the jrebel.lic is correct, search the jrebel.log for “License information:”. The “limitedUntil” field defines how long the license is valid

Classes or resources don’t reload

Possible problems when JRebel is set up and started correctly (JRebel startup banner visible in the console), but the classes do not get reloaded:

  • First a precaution: if you’re testing JRebel and think that classes aren’t being reloaded, check your assumptions. Note that JRebel only issues a console statement when a previous version of the class has already been loaded, so just changing some class doesn’t cause it to reload, unless you accessed it before.
  • Are the classes monitored? The first thing to check is that JRebel actually monitors the directories with compiled classes in your workspace. To do this, search the jrebel.log for the “monitored for changes” phrase. If you don’t find any then probably rebel.xml hasn’t been generated or at least isn’t present or recognized in the application archive. If the monitored dirs are present, then you now know exactly where JRebel is expecting to find updated classes and resources and can check them accordingly. Take a look at the reference manual if you’re not sure what rebel.xml is or not sure if you placed it correctly.
  • If you couldn’t find any monitored dirs, it could be that your rebel.xml isn’t present in the application archive or it’s incorrect. To find out, search for “rebel.xml” in the jrebel.log. It will show you both where the rebel.xml is found from and its content. You can search the jrebel.log for “does not exist” to make sure that all directories mentioned in the rebel.xml actually exist.
  • Once you’re convinced that JRebel is monitoring directories, it should definitely pick up changes to the resources. However to make sure that changes to classes are picked up search jrebel.log for “instrumented”. JRebel issues a log statement with that word for each class it loaded and will be monitoring for changes. If such a statement is missing then that class probably hasn’t been loaded, check that you are testing the same application you are updating.
  • Do the classes get recompiled? If you checked that both the dirs and the classes are monitored, be sure to check that the classes are being compiled. Does your IDE support auto-compile on save feature? Or compile the changed classes manually. Find the “instrumented” class statement in the “jrebel.log” for the class you will be updating, it also tells you exactly what .class file it’s reloaded from. Find that .class file and monitor its timestamp (last modified time), while updating it from the IDE. If the timestamp doesn’t change, you should check your compilation settings in the IDE and that the monitored directory is the same as the IDE output directory.
  • Does the reloaded code get re-executed? When you’re changing a constructor or initializer method on an already created object, chances are that it won’t be run again. Even if JRebel does reload the class, it won’t actually reflect in the application until you recreate that component.

The debugger is broken!

Did you install the IDE plugin? No, seriously, it’s very important that you do! Check out the reference manual.

I checked everything and it still doesn’t work!

That sucks, it’s probably our fault somehow. But hey, if it doesn’t work for you, probably someone else had this problem already, so a good idea is to search the forum. Also, we often fix issues (and introduce new ones) in the nightlies long before they get to the release, so grabbing one is an option. And even if that doesn’t help, don’t worry! You have a direct line to the development team via the forum and email. Just let us know and we’ll be glad to help you with your issues. A good idea is to include a zipped jrebel.log (per instructions above) when writing to support, this will be the first thing we ask you for anyway :)

Try to be as specific as you can with the information about your environment: Java version, application server (and version), what are the frameworks that are used in your application, etc – this information will greatly speed up the investigation.