JRebel Frequently Asked Questions

JRebel is:

• A Java development-time tool. JRebel decreases turnaround by instantly reloading changes to your code. This is done without having to restart the container or redeploy the application.
• A plugin for the JVM. The -agentpath command line option allows custom instrumentation plugins to be registered. JRebel uses this option for running.
• A single JAR file. That pretty much says it all. There is no installation process: just unzip, copy, add options to the command line and enjoy! Even easier when using a JRebel IDE plugin.

JRebel is not:

• 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 remove it at any moment and continue developing the way you did previously.
• An application server. JRebel does work with all prominent application servers, but it is not one itself.
• A custom JVM. JRebel does not require you to make any changes to the JVM. JRebel works with all prominent JVM implementations.

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.

JRebel 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 supplied with plugins for all common frameworks out of the box. For a full list, please check the integrations section.

Yes. JRebel’s free download includes a fully featured 14-day trial license. If you think that two weeks is not enough, ask for an extension from sales@perforce.com.

Rebel Licenses (formerly known as ZT License Management) is a hosted, always online licensing service. This service provides immediate access to JRebel & XRebel licenses for use online or in offline mode (where available). The Rebel Licenses also provides analytical capabilities and advanced user monitoring.

From here you have access to the Rebel Licenses user documentation, including overviews for the following views:

• Dashboard
• Teams
• Users
• Administrators
• Analytics
• Configuration
• Activating products
• Security overview
• Troubleshooter
• FAQ

JRebel is available as an IDE plugin for all major IDEs: Eclipse, IntelliJ IDEA, NetBeans, MyEclipse, Rational Application Developer, and JDeveloper. You will find JRebel in the list of plugins available for your IDE. Please refer to the Quick Starts for more details.

In case if you require a standalone archive of JRebel, you can download a ZIP archive.

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.

When using an IDE, you can simply enable JRebel by following instructions in the Quick Start.

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

When 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.

When JRebel is installed successfully, the following banner should be displayed in the console or standard output when the JVM is started up:

2018-05-11 15:23:29 JRebel:  #############################################################
2018-05-11 15:23:29 JRebel:  
2018-05-11 15:23:30 JRebel:  JRebel Agent 2018.1.1 (201805041400)
2018-05-11 15:23:30 JRebel:  (c) Copyright ZeroTurnaround AS, Estonia, Tartu.
2018-05-11 15:23:30 JRebel:  
2018-05-11 15:23:30 JRebel:  Over the last 1 days JRebel prevented
2018-05-11 15:23:30 JRebel:  at least 0 redeploys/restarts saving you about 0 hours.
2018-05-11 15:23:30 JRebel:  
2018-05-11 15:23:30 JRebel:  Licensed to ZeroTurnaround
2018-05-11 15:23:30 JRebel:  
2018-05-11 15:23:30 JRebel:  
2018-05-11 15:23:30 JRebel:  #############################################################

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

JRebel supports all prominent application containers, including Oracle WebLogic, IBM WebSphere, JBoss EAP, WildFly, GlassFish, Tomcat, Jetty and Spring Boot. For a full list, please check the list of integrations.

JRebel supports basic class reloading with any Java framework. JRebel also has special support to reload configurations of specific frameworks. To find out more, check the JRebel integrations page.

No, you do not.

Yes. A respective IDE plugin is required to debug an application when JRebel is enabled. Please see the Quick Start for installation instructions.

For IDEs, check out the Quick Start. Select your platform in the reference manual.

If you have a Maven project imported into you IDE, you don't need to do anything specific to configure it. JRebel IDE plugin can take care of rebel.xml generation, and you can run or deploy it like any other project.

Additionally, we provide a JRebel Maven plugin to generate rebel.xml configuration files for the project during build. Check how to configure the JRebel Maven plugin and how to enable the JRebel agent when starting the application via a Maven plugin (e.g. Jetty Maven plugin).

JRebel monitors the folders from which classes are loaded and those which are specified in the rebel.xml configuration file.

JRebel uses the operation system's functionality to notify applications about file changes. For system where this is not supported, JRebel will check a file's last modified timestamp to determine if it has changed.

No. If you do experience a significant decrease in performance, please contact Support-Rebel@perforce.com.

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 you do experience a significant decrease in performance, please contact Support-Rebel@perforce.com.

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 for JRebel to work, some memory and performance overhead is added. In a production environment, additional overhead like that is not desirable.

Check the following:

• Does the application still start without JRebel?
• Is there an exception in the console output? If it is too cryptic, just send it to Support-Rebel@perforce.com.

Please check out the first aid guide.

JBoss’s approach for monitoring application descriptor files can cause the “Too many open files” on *nix machines with a low limit of open files per user. The current solution is to increase the number of file handles or to disable 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 application server via sudo bash -c 'ulimit -n 8192; sudo -u yourUserName ./appServerStartupScript'. Permanent user configuration is done by editing the /etc/security/limits.conf and adding the lines yourUserName hard nofile 8192 and yourUserName soft nofile 8192 at the end of this file.

Since JRebel replaces hot-swapping, it is normal that the IDE will show an error when trying to replace the code. We recommend ignoring it because JRebel does not depend on any IDE and will reload the changes when the class in question or its instance is accessed.

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

Setting a conditional breakpoint can fail when the expression is not altered. To save time, simply write the condition in the class text and then set the breakpoint inside the condition:

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

When using a JRebel IDE plugin, open Help > JRebel > Submit a support ticket and follow the instructions.

When not using an IDE plugin, please refer to sending logs page and send your issue description to Support-Rebel@perforce.com.

No, files asked by support do not contain your source code, although might contain some class info (specified below). The two files commonly asked by support (and automatically sent if you use the IDE built-in support dialog) are the JRebel Agent log (jrebel.log) and the JRebel IDE plugin log (e.g. jrebel-eclipse.log).

JRebel Agent log contains runtime information about JRebel Agent loading and instrumenting your classes (e.g. which class was loaded from where and by which class loader), your rebel.xml configuration, licensing info, information about your environment (e.g. JVM arguments), and log of all activities performed by JRebel Agent, e.g. reloading a class or reloading framework configuration. If you set log level to "trace", then JRebel Agent log will additionally contain class info, including superclass info, method names, field names, annotations, annotation values.

JRebel IDE plugin log contains information about user's activity with the JRebel plugin, e.g. it contains a log about communication with JRebel remote servers.

JRebel uses the rebel.xml configuration file to map the deployed application back to your workspace. JRebel cannot reload classes without this configuration file.

For more information, please refer to application configuration using rebel.xml.

Yes. Every classpath entry (folder, JAR/WAR/EAR file) you want to reload classes from, should have its own rebel.xml file. This is usually easiest accomplished by adding a rebel.xml to each module in your project.

When using the JRebel IDE plugin, refer to the Quick Start for project configuration and rebel.xml generation.

When using external build tools, please refer to:

• JRebel Maven plugin
• JRebel Gradle plugin

First of all, please check that you are on an up-to-date version of JRebel. Proxy support in JRebel has some recent improvements.

Next, make sure that you have a network connection and a valid route to the server. To do this, paste the team URL (aka group URL) into your browser and verify that you can see a page rendered by the License Server or ZT License Management (ZTLM).

If you do not see the page in the browser, check your network connection and proxy settings. If the License Server instance is set up within a corporate VPN, make sure you are connected to it.

If you can open the team URL in the browser, but the JRebel IDE plugin is unable to acquire a license from the team URL, please review your IDE proxy settings as follows:

• In Eclipse, you can find proxy settings under Settings > General > Network Connections.
• In IntelliJ IDEA, find proxy settings under Settings > Appearance & Behavior > System Settings > HTTP Proxy.
• In NetBeans, check under Options > General > Proxy Settings.

If the JRebel IDE plugin can acquire a valid license, but the JRebel Agent cannot, add the following to your jrebel.properties file:

rebel.ide.forward_proxy_args=true

Alternatively, specify the proxy settings directly on the JVM, using the flags http.proxyHost and http.proxyPort. Be aware that this will also proxy any other outgoing HTTP connections from your application.

Another workaround for situations where you can reach the License Server from the IDE - but not from the Agent - is to acquire an offline seat from the IDE.

JRebel uses a dedicated folder for storing configuration files and logs. This folder is located in $USER_HOME/.jrebel. Make sure that this folder has read/write permissions for the current user.

Alternatively, use the REBEL_BASE system environment variable to specify another location. For more instructions, refer to base folder configuration.

Yes. Mapping webapp resources (using the rebel.xml configuration file) will make updates to those files visible to the application server. If the application does not load these resources just once during initialization or cache them, updates will become visible in the application.

JRebel is a desktop tool in developer's machine. It's not a web application that you could communicate with over network, making the HTTP/HTTPS question not applicable. There is no incoming/outgoing traffic to/from JRebel (except for product usage statistics, which can be turned off).

View JRebel data processing details. Immediately after the activation of JRebel, the product will ask if you want to opt out of any data processing. This ensures JRebel is fully GDPR-compatible.

Exception is JRebel's remote server support. When a developer uses JRebel to update code in remote servers, he is essentially sending parts of his application code over network. If he uses public network, he should use HTTPS connection (which the product supports). Vast majority of JRebel users are not using this feature.

In a nutshell: it's a software tool whose effect is limited to the work the developer does on his code on his desktop machine. (Compare to for example a text editor, a video player, etc.) It's not an information system that could be attacked for sensitive data.