JavaRebel is a developer tool that will reload changes to compiled Java classes on-the-fly saving the time that it takes to redeploy an application or perform a container restart. It is a generic solution that works for Java EE and Java standalone applications.
JavaRebel installs as a JVM plugin (-javaagent) and works by monitoring the timestamp of class files. When it is updated (e.g. when a developer saves a class from the IDE) JavaRebel will reload the changes to class code and structure while preserving all existing class instances. The loading is lazy and will happen upon usage of the class (method call on an instance, static call on the class, field lookup etc).
The following classes will be reloaded when they are changed and compiled:
All “.class” classes inside the usual classpath (WEB-INF/classes, etc). Using this with exploded deployment will provide the best JavaRebel experience.
All “.class” files in directories specified by -Drebel.dirs (comma-separated list) JVM command line property. With this you can deploy in unexploded development mode (EAR or WAR) and still reload classes instantly. For example -Drebel.dirs=/path/to/eclipse/project-one/bin,/path/to/eclipse/project-two/bin. However new classes (or renamed old classes) will not be loaded before they also appear in the classpath (e.g. after the build in JAR files).
Example: Java EE exploded development
You are developing a Java EE application. You are using exploded development and have deployed the root of your project to the container. The container is loading your classes from WEB-INF/classes. You have installed JavaRebel to the container.
To take advantage of this situation with JavaRebel the developer has to start compiling the class files straight to WEB-INF/classes and instead of redeploying the application JavaRebel will reload code changes.
Example: Java EE unexploded development (WAR or EAR)
You are developing a Java EE application. You are using unexploded development and have deployed a WAR archive to the container. You would like to change Java source files and see the changes propagate without redeploy. You are compiling your classes to c:\projects\app\build\classes.
To take advantage of this situation with JavaRebel the developer has to start the container with JavaRebel and also specify the location of the classes, thus -Drebel.dirs=c:\projects\app\build\classes. JavaRebel will now reload new classes that are compiled to c:\projects\app\build\classes.
Example: Java SE development
You are developing a Java SE Swing application. You are compiling and starting it from an IDE with all the compiled classes being in system classpath. In this case adding the JavaRebel installation command line to the started application will immediately enable class reloading.
Running java -jar /path/to/javarebel.jar will generate a javarebel-bootstrap.jar. The file is generated
to the folder where javarebel.jar resides.
IMPORTANT!javarebel-bootstrap.jar is JVM and JavaRebel version specific! If you upgrade your JVM (even a minor version) or upgrade JavaRebel you have to regenerate javarebel-bootstrap.jar.
IMPORTANT! Make sure that the JVM version used to generate javarebel-bootstrap.jar is the same your application will run with!
Example
java -jar C:\libraries\javarebel.jar - will generate a javarebel-bootstrap.jar into the folder C:\libraries\
java -jar /home/john/lib - will generate a javarebel-bootstrap.jar into the folder /home/john/lib
NOTE The easiest way to ensure JVM and JavaRebel version consistency is to add the javarebel-bootstrap.jar generation to the startup script of your application server. This means that on every startup the javarebel-bootstrap.jar is generated with the JVM that is used to start the server. This is an inexpensive invocation and will not be noticeable.
Adding commandline options to the JVM
JavaRebel requires the javarebel-bootstrap.jar and javarebel.jar to be prepended to the Java bootclasspath as well as the -noverify JVM flag:
See Features for supported JVM and server versions.
IDE configuration
If you are using IntelliJ IDEA you should install this plugin to enable debugging with JavaRebel. You should also configure your IDE for better debugging experience.
Instructions per container
Further you can find specific instructions for different operating systems, application servers and so on. To keep the instructions concise we don’t include the -Drebel.dirs option in the following installation strings.
WebSphere support is currently experimental and does not support -javaagent style of installation. Also the installation requires to add the IBM ibmjceprovider.jar to bootclasspath.
Generate the javarebel-bootstrap.jar by running java -jar javarebel.jar using the JVM you will run the application server with (you can also add this line to the startServer.sh after the environment is set).
Edit the file server.xml found in the server profile. Modify the tag jvmEntries and add the attribute genericJvmArguments with the value -noverify -Xbootclasspath/p:/path/to/javarebel-bootstrap.jar:/path/to/javarebel.jar:WAS_JAVA_HOME/jre/lib/ext/ibmjceprovider.jar
Note that as WebSphere does not properly support exploded development mode you have to set the “-Drebel.dirs” as specified earlier.
Oracle Application Server 9.x (on Java 5)
Windows
Go to folder %ORACLE9_HOME%\j2ee\home and start the server with the following command:
Search for jvm-options element and add the elements -noverify and -javaagent:javarebel.jar
Start the domain as usual.
Maven/Jetty
You can also use JavaRebel with Maven Jetty plugin.
Edit your pom.xml file and set the scanIntervalSeconds param to 0, this will turn off Jetty’s internal reloading. Jetty’s internal reloading won’t keep your session after reloading changed classes.
Start jetty with the maven jetty plugin and the MAVEN_OPTS parameter set
Since Jetty does not have any startup scripts just add the following line to the command line:
-noverify -javaagent:javarebel.jar
Caucho Resin 3.0.x
Copy javarebel.jar to RESIN_HOME/ folder.
Windows
Start httpd.exe with parameters
httpd.exe -J-javaagent:javarebel.jar -J-noverify
Linux
Modify RESIN_HOME/bin/wrapper.pl $JAVA_ARGS variable to include the line:
-javaagent:javarebel.jar -noverify
Other
If JavaRebel doesn’t work with your application or container it is most probably due to some custom classloaders that don’t behave exactly as we expect them to. You need to determine the class name of the classloader in question. The easiest way to do it is put the following line in any class that will be loaded by that classloader (e.g. in a web application case it could be a servlet class):
This will print the name of the classloader class right out to the console. Let’s assume the name was “com.acme.CustomClassLoader”. In that case all we need to do is pass it to the JavaRebel agent like this:
To generate the javarebel-bootstrap.jar just run java -jar javarebel.jar using the JVM you will run the application with.
Edit your pom.xml file and set the scanIntervalSeconds param to 0, this will turn off Jetty’s internal reloading. Jetty’s internal reloading won’t keep your session after reloading changed classes.
Start jetty with the maven jetty plugin and the MAVEN_OPTS parameter set