What is/isn’t JRebel?

JRebel is

  • A Java development-time tool that decreases turnaround by instantly reloading changes to your code, 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 JAR file about 1 MB big. 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 sales@zeroturnaround.com.


Licensing options

Dedicated – Each license is assigned to a particular person and is sent to the person’s email address. The license can be transferred to a different person by contacting sales-operations@zeroturnaround.com. License will be delivered to the License Owner email address.

JRebel Floating – Floating licenses are uploaded into a license server that each developer connects to. A license is pulled down and used as needed. There can be as many concurrent users as the amount of licenses and all the savings are reflected onto the license server with no limitation on the number of unique users.

See License Server features.


Do you offer refunds?

We offer a 30 day “no questions asked” refund policy.


Can I use my license on several machines?

Technically yes. Dedicated licenses are tied to an individual developer and that person can use it on any machine. Floating licenses can be accessed from multiple machines as long as there is a token available.


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 reference manual 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 on the download page.

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:

##################################################

  JRebel 5.2.0 (201302271426)
  (c) Copyright ZeroTurnaround OU, Estonia, Tartu.

  Over the last 30 days JRebel prevented
  at least 56 redeploys/restarts saving you about 2.6 hours.

  You are running with an evaluation license.
  You have 12 days until the license expires.

  You will see this notification until you obtain a
  full license for your installation.

  Visit www.jrebel.com for instructions on obtaining
  a full license. If you wish to continue your evaluation
  please e-mail to support@zeroturnaround.com.

  If you think you should not see this message contact
  support@zeroturnaround.com or check that you have your
  license file in the same directory as the JAR file.

  If you think you should not see this message contact
  support@zeroturnaround.com or check that you have your
  license file in the same directory as the JAR file.

##################################################

Does JRebel support JVM vendor X version Y?

JRebel supports Java starting from 1.4 by all prominent JVM vendors, including Sun, IBM and Oracle. The list of the JVM vendors that JRebel has been tested on can be found on the JRebel features page.


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 see JRebel features page.


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?

No.

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 reference manual for installation instructions.


Where can I find installation instructions for my particular environment?

Select your platform in the manual.


How do I configure my IDE to work with JRebel?

Check your IDE box in the Tools in the installation 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. Timestamps checks happen only when the class is used in the program. Either there is a field lookup, method invocation, static method invocation etc.


Does JRebel scan all my classes all the time? Isn’t that slow?

No, it doesn’t. It only checks the class file timestamp if the class is being used in the application.


Does JRebel slow my system down?

No. If you see significant decrease in performance please contact support@zeroturnaround.com.


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 support@zeroturnaround.com.


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 support@zeroturnaround.com 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
}

Why do I get NullPointerException when accessing a newly added field?

JRebel will always reload changes to the fields, however newly added fields will not always be initialized:

  • Non-static fields will be initialized once a new class instance is created. This is due to the way Java handles field initialization, which gets run only on constructor calls. Since primitive types cannot be initialized to nulls such fields will cause a NullPointerException on access. Object types will cause a NullPointerException when dereferenced.
  • Static fields will never get initialized. Again, Java appends the static fields initialization to the ends of the single static initializer method <clinit>. Rerunning this method is dangerous, since it can overwrite or alter meaningful state. This does not concern constants (final static primitive or String fields) as they are replaced by their proper values and therefore will get initialized.

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 to the same directory as JRebel.jar
  • 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!
  • If you need private support just drop us an email at support@zeroturnaround.com 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 plugin page for more information.


How do I install plugins?

Official plugins are on the plugin page and included in the JRebel JAR file (if not stated otherwise). You will need to enable them depending on which framework you are using. JRebel will print out the list of found plugins on application startup and instructions on how to enable those specific plugins.

Also you can find the list of plugins in the IDE plugin settings and enable/disable the plugins according to your preferences. See reference manual for more information.


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.