Frequently asked questions – FAQ

General FAQ

What JRebel is and what it is not?

JRebel is

  • A Java development-time tool that decreases turnaround by instantly reloading changes to your code. All this without having to restart the container or redeploy the application.
  • A JVM -javaagent plugin. The -javaagent is a command line option that has been available since Java 5 to allow custom instrumentation plugins to be registered. JRebel uses this option for installation.
  • A single JAR file. That’s pretty much says it all – there is no long installation process: just unzip, copy, add options to the command line and enjoy!

JRebel isn’t

  • An IDE plugin. JRebel comes pre-bundled with the plugins for Eclipse, IntelliJ IDEA, NetBeans and JDeveloper, however, JRebel agent is designed to be IDE-agnostic and can be used outside the IDE.
  • A framework. JRebel does not introduce any dependencies in your application. You can take it away at any moment and just continue developing the way you do normally.
  • An application server. JRebel works with all prominent application servers, but it definitely isn’t one.
  • A custom JVM. JRebel doesn’t require you to make any changes to the JVM and works on all prominent JVM implementations.

How does JRebel work?

JRebel integrates with the JVM and application servers mainly on the class loader level. It does not create any new class loaders, instead, it extends the existing ones with the ability to manage reloaded classes.

When a class is loaded JRebel will try to find a corresponding .class file for it. It will search from the classpath (including an application classpath, like WEB-INF/classes) and from the places specified in the rebel.xml configuration file. If it find a .class file JRebel instruments the loaded class and associates it with the found .class file. The .class file timestamp is then monitored for changes in the loaded class and updates are propagated through the extended class loader, to your application.

JRebel can also monitor .class files in JARs if they are specified in rebel.xml.

Importantly, when loading updates to a class, JRebel preserves all of the existing instances of that class. This allows the application to just continue working, but also means that when adding a new instance field it will not be initialized in the existing instances, since the constructor will not be rerun.

Some common misconceptions:

  • JRebel just wraps class loaders around classes.

    In fact JRebel does not add a single new class loader to your application. The solution of reloading Java classes by wrapping them in throwaway classloaders is a well-known one, but unfortunately also very limited. The problem is that unless you also throw away all of the instances of the classes loaded by said class loaders, the code will not reload. However throwing away those instances is only possible if they are somehow managed by the framework, e.g. as it’s done in Tapestry 5.

  • JRebel just uses Instrumentation API.

    The Instrumentation API was introduced in Java 5 and included a limited ability to redefine Java classes on-the-fly. Unfortunately it is limited to only changing method bodies (as is HotSwap) and also suffers from several additional quirks, which makes it not too useful in a real environment. JRebel agent does use it to instrument the application server class loaders and other basic classes, but the API does not play part in the actual reloading process.

Aren't there free/open source alternatives that do this already?

In one word: no. However there are several partial solutions:

  • Hot deploy.

    This is basically when your application is redeployed on any change to the code. Most application servers will allow you to do that. The problem is that it only works for small or lightweight applications. Your typical enterprise application will redeploy for at least 30 seconds and this time is just wasted. With JRebel the reloading time is measured in milliseconds.

  • HotSwap.

    HotSwap is a technology available in Java since 1.4 that allows you to instantly redefine Java classes inside a debugger session. This is supported by all prominent IDEs (e.g. IntelliJ IDEA, Eclipse and NetBeans), so if you attach a debugger to your application and make some changes, they will be reflected immediately. Unfortunately this technology is very limited, as it only allows changes to method bodies and doesn’t allow new classes to be added. JRebel can be thought of as improved HotSwap, as it allows changes to class structure, including adding methods, fields, constructors and even annotations as well adding classes and changing configurations.

  • OSGi.

    OSGi is a runtime module container for Java. It allows you to split an application into modules with well-defined dependencies and manage them separately. One of the side-effects is that it allows you to update the modules (or, in OSGi-speak, bundles) one at a time. It is basically the same solution as Hot Deploy, but since the module size is smaller than the application size, the time wasted can be smaller. It will still likely be measured in tens of seconds, since all of the dependent modules should also be updated, but it can be significantly faster than vanilla WAR/EAR applications. JRebel reloading time is still orders of magnitude faster.

  • Throwaway class loaders.

    Several frameworks (including Tapestry 5, RIFE, Seam, Grails and so on) will instantly reload the changes to the code of the managed components (e.g. beans, pages, controllers, etc). This is possible by wrapping a throwaway class loader around the managed component and recreating its instance after every change. Unfortunately this solution works only for managed components and the rest of the code cannot be reloaded. It can also cause weird ClassCastExceptions and other similar problems due to class loader migration problems. JRebel works for any class in your system, preserves all the current object instances and does not exhibit any class loader-related problems.

What about configuration changes?

Reloading changes to Java classes is not always enough. Applications include configurations for Java code, annotations, XML files, property files and so on. JRebel uses configuration-specific plugins to reload those changes instantly, just as it does changes to classes. JRebel comes with plugins for Spring, Guice, Stripes, Tapestry 4 and others out of the box. To find out more check out check out our OSS projects’ overview.

Free trial

JRebel’s free download includes a fully featured 14-day trial license. If you think that 2 weeks is not enough you can always ask for an extension from

Licensing options

Please refer to the licensing FAQ page for more information.

How do I install JRebel?

JRebel is distributed as an IDE plugin for all major IDEs – Eclipse, IntelliJ IDEA, NetBeans, JDeveloper. You will find JRebel in the list of plugins available for your IDE. Please refer to the Quick Start for more details.

In case if you require a standalone archive of JRebel, you can download a ZIP archive from the web site.

What is exploded and packaged deployment?

The classic way of deploying a (web) application to a Java EE container involves packaging all the classes and resources into one file (WAR or EAR) and uploading it to the server, or pointing the server to it. We refer to such type of deployment as packaged.

Most containers also support an alternative way of deploying an application, where you create a directory with a WAR or EAR structure and point the container to it. This is usually referred to as exploded.

What do I have to change in my application for JRebel to work?

If you are using an IDE, you can just enable JRebel per the instructions in the Quick Start.

If you are using exploded deployment you just have to set your IDE to compile to the directories in the application classpath (e.g. WEB-INF/classes).

If you’re using packaged deployment you should create a rebel.xml configuration file and put it in the application classpath (e.g. WEB-INF/classes).

Please see the reference manual for details.

How do I know that JRebel is working?

If JRebel is installed successfully, the following banner should be displayed in the console or standard output:

2014-12-05 16:54:17 JRebel:  #######################################################
2014-12-05 16:54:17 JRebel:  
2014-12-05 16:54:17 JRebel:  JRebel Agent 6.2.0 (201411250830)
2014-12-05 16:54:17 JRebel:  (c) Copyright ZeroTurnaround AS, Estonia, Tartu.
2014-12-05 16:54:17 JRebel:  
2014-12-05 16:54:17 JRebel:  Over the last 1 days JRebel prevented
2014-12-05 16:54:17 JRebel:  at least 0 redeploys/restarts saving you about 0 hours.
2014-12-05 16:54:17 JRebel:  
2014-12-05 16:54:17 JRebel:  Licensed to ZeroTurnaround.
2014-12-05 16:54:17 JRebel:  
2014-12-05 16:54:17 JRebel:  #######################################################

Does JRebel support JVM vendor X version Y?

JRebel supports Java starting from 1.5 by all prominent JVM vendors, including Sun, IBM and Oracle.

Does JRebel support application container X?

JRebel supports all prominent application containers including Oracle Weblogic, IBM WebSphere, JBoss AS, Oracle OC4J, Sun GlassFish, Tomcat and Jetty. For a full list, please refer to running JRebel from command line.

Does JRebel support framework X?

JRebel will reload classes managed by any framework. JRebel also has special support for some frameworks to enabled reloading their configuration. To find out more check out JRebel features page.

Do I have to run JRebel in a debugger session?


Can I debug the application with JRebel enabled?

Yes. A corresponding IDE plugin is required in order to debug application managed by JRebel. Please see the Quick Start for installation instructions.

Where can I find installation instructions for my particular environment?

Select your platform in the manual.

How do I get JRebel working with Maven?

We provide a Maven plugin to automatically generate rebel.xml configuration files for the project. Check how to configure the JRebel maven plugin and how to enable JRebel agent if you start the application via some maven plugin (e.g. Jetty maven plugin).

How does JRebel know what classes have been changed?

JRebel checks the file timestamps of the class files on the filesystem. If the timestamp has changed the new class is reloaded.

Does JRebel slow my system down?

No. If you see significant decrease in performance please contact

Does JRebel make the server start up slower?

JRebel needs to do more work on startup (search more places for classes and resources, instrument classes, etc), so some slowdown can be expected. If it’s larger than 50% please contact

Should JRebel be used in production environments?

We do not recommend using JRebel in a production environment.

JRebel is a development tool and therefore meant to be used only in a development environment. Keep in mind that in order for JRebel to work, some memory and performance overhead is added. In a production environment, added overhead like that is not desirable.

I installed JRebel and my application doesn't start. What do I do?

  • Does the application start without JRebel?
  • Is there an exception in the output? If it is too cryptic just send it to or post it on the forum.

I installed JRebel and it doesn't reload classes. What do I do?

Please check out the first aid guide.

Why doesn’t JRebel reload the changes in the TEST I made?

There are also some limitations that apply for small tests only. Please read Testing JRebel if you intend to try it on small tests.

I'm getting java.lang.OutOfMemoryError: PermGen space!??

If you have a large number of classes in your application, then the above exception may occur – running your application with JRebel requires a little bit more memory than running without. Although the exact amount depends on the application itself, we usually find that it falls somewhere between 10-15% extra. Our recommendation is to start from there and then bump it up until the exception stops occurring. Also, in general, we recommend at least 128 MB as the PermGen size for your application/server. You can use the flag -XX:MaxPermSize=128m to configure the amount of available PermGen memory.

I get 'Too many open files' message

JBoss’s approach for monitoring application descriptor files can cause a message “Too many open files” on *nix machines with a low limit of per user open files. The current solution is to increase the number of filehandles or disabling JBoss URLDeploymentScanner from jboss-service.xml.

The limit of open files can be verified by ulimit -a. Increasing of the limit requires root privileges and can be done for the running of the application server via sudo bash -c 'ulimit -n 8192; sudo -u yourUserName ./appServerStartupScript'. Permanent per user configuration is via editing the /etc/security/limits.conf and adding the lines yourUserName hard nofile 8192 and yourUserName soft nofile 8192 at the end of the file.

Why does my IDE show an error “hot code replace failed”?

Since JRebel replaces hotswapping it is normal that IDE will show an error when trying to replace the code. Just ignore it, JRebel does not depend on any IDE and will reload the changes when the class in question or its instance is accessed.

Why does setting a breakpoint in debugger does not work?

Did you install the IDE plugin? The IDE plugin helps the debugger to understand that there are the new executable lines of code and help to re-install the breakpoints.

Why do I have trouble setting a conditional breakpoint?

For the same reason described above setting a conditional breakpoint can fail, if the expression is not altered. To save some thinking you can just write the condition in the class text and then set the breakpoint inside the condition:

if (myCondition) {
	System.out.println(); //Breakpoint

How do I report errors? What kind of information should I include?

When you’re reporting issues to us please try to include a JRebel log file with it.

  • Start your application with -Drebel.log=true and a jrebel.log file is generated into the $USER_HOME/.jrebel folder.
  • The log file contains all the necessary system information. JDK version, operating system, properties passed to the application, classloading logic etc.
  • If the file is too large, compress it with ZIP, GZip or your favorite compression algorithm.
  • If for some reason the log is not generated or you don’t have the time to generate it, please provide JDK, application server and any important library versions. Also knowing the operating system can help a lot!
  • Should the error in question be caused by a specific part of code, please include that part of the code in the support email.
  • If you need private support just drop us an email at with the information mentioned above.

What do I need plugins for?

Although class reloading is extremely sexy and gives you a great productivity boost there is more that you can do. Reloading framework configuration or framework configured components means that you don’t have to redeploy when adding a new Spring bean or configuring a new Tapestry listener. See the integrations page for more information. All plugins are enabled by default. You should only consider disabling these plugins in case of conflicts.

Where are you guys based out of?

We are based in Estonia, in a small university town called Tartu. Estonia is a small country with a population of the size of San Diego, California.

Is it true, that Skype, Kazaa and Microsoft are also from Estonia?

Skype and Kazaa were developed in Estonia, Microsoft was founded in the US.

We hope you all your questions were answered by the JRebel FAQ.

We are always looking to improve the FAQ, so if we missed something, let us know.