First aid

This chapter documents common JRebel problems and provides ways to resolve them.

Tip

Before you continue, enable logging. The JRebel log files help you and JRebel Support to troubleshoot issues. Make sure you have enabled logging by adding -Drebel.log=trace to the startup parameters – or confirm the logging settings in your JRebel IDE plugin settings via Help > JRebel > Configuration. The default location of the log file is in the {user.home}/.jrebel folder.

Whenever JRebel Support asks you for the log files, refer to sending logs for more information.


Server or application fails to start

You completed the JRebel setup successfully, but for some reason your server or application does not start. Here is what you can do.


JRebel agent is not found

Problem: This message is shown in the log:

Error opening zip file: /jrebel/jrebel.jar ... Error occurred during initialization of VM agent library failed to init: instrument

Solution: The path leading to -agentpath is incorrect. Confirm the exact location of JRebel and specify that path with -agentpath:[path/to]jrebel. For more information, please refer to running server from command line.


JRebel fails to start with Java 1.4 or IBM JDK

Problem: JRebel fails to start when using Java 1.4 or IBM JDK.

Solution: Make sure that you generate jrebel-bootstrap.jar with the exact same JVM version and JRebel version that the server is started with. To generate jrebel-bootstrap.jar, execute java -jar jrebel.jar. Make sure that the java -version is correct.


How to use JRebel on a JDK version older than Java 8

Problem: How can I use JRebel on a JDK version older than Java 8?

Solution: Download JRebel version 2022.1.2 and run -agentpath:path/to/jrebel.jar to use JRebel with older JDK versions.


JRebel runs out of memory

Problem: JRebel fails to start due to a OutOfMemoryError error.

Solution: Try adding more memory to the heap. When permgen space is mentioned, add -XX:MaxPermSize=128M (increase the number where necessary) to the JVM command line parameters. Otherwise, add -Xmx256m or increase this number if already present. Keep in mind that running out of memory or permgen space can cause the JVM to crash altogether.


JRebel fails to start

The following console banner is always shown when JRebel starts successfully:

2024-04-02 14:23:55 JRebel:  #############################################################
2024-04-02 14:23:55 JRebel:
2024-04-02 14:23:55 JRebel:  JRebel Agent 2024.1.0 (202001051049)
2024-04-02 14:23:55 JRebel:  (c) Copyright 2007-2024 Perforce Software, Inc.
2024-04-02 14:23:55 JRebel:
2024-04-02 14:23:55 JRebel:  Licensed to John Rebel
2024-04-02 14:23:55 JRebel:
2024-04-02 14:23:55 JRebel:  License type: dedicated
2024-04-02 14:23:55 JRebel:  Valid from: April 1, 2019
2024-04-02 14:23:55 JRebel:  Valid until: March 31, 2024
2024-04-02 14:23:55 JRebel:
2024-04-02 14:23:55 JRebel:  #############################################################

If this does not show up, here are the things to check.


Confirm JRebel is present in startup parameters

Check that -agentpath:path/to/lib/libjrebel gets to the JVM command line. When you changed %JAVA_OPTS% or %JAVA_OPTIONS% to include it, try adding echo %JAVA_OPTS% to the server startup script.


Make sure you are looking at the right console

With some application servers (e.g. WebSphere and GlassFish), it is possible that the banner is shown, but hidden in one of the console output logs. Check those logs to find it. Or check jrebel.log to confirm JRebel launch.


JRebel evaluation license has expired

Seeing this message means that the 10-day JRebel evaluation is over. However, sometimes this is shown even when you have a valid license. In that case:

  • Check that jrebel.lic is present in your {user.home}/.jrebel folder.

  • To verify jrebel.lic, search jrebel.log for “License information”. The limitedUntil field defines when the license is going to expire.


Classes or resources are not reloaded

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

Tip

Keep this in mind: when you are testing JRebel and think that classes are not being reloaded, be absolutely sure. Note that JRebel only issues a console statement when a previous version of the class has already been loaded. Just changing some class does not cause it to be reloaded – 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 jrebel.log for “monitored for changes”. If you do not find any, then probably rebel.xml has not been generated, or it is not present or recognized in the application archive. If the monitored folders are present, you know exactly where JRebel is expecting to find updated classes and resources. Check these accordingly. Refer to rebel.xml configuration in the reference manual for more information.

  • If you cannot find any monitored folders, it could mean that your rebel.xml is not present in the application archive or that it is incorrect. To find out, search for “rebel.xml” in jrebel.log. It will show you both where the rebel.xml is found from and its content. You can search jrebel.log for “does not exist” to make sure that all folders mentioned in rebel.xml actually do exist.

  • Once you are convinced that JRebel is monitoring these folders, it should pick up changes to the resources. However, to make sure that changes to classes are picked up, search jrebel.log for the term “instrumented”. JRebel issues a log statement with this word for each class it loaded and will be monitoring for changes. If such a statement is missing, that class probably has not been loaded. In this case, make sure your deployed application reflects the source code.

  • Do the classes get recompiled? If you checked that both the folders and classes are monitored, be sure to check that the classes are being compiled. Does your IDE support the auto-compile on save feature? If not, make sure to compile the changed classes manually. Find the “instrumented” class statement in jrebel.log for the class you will be updating. This also tells you exactly what .class file it is reloaded from. Find that .class file and monitor its timestamp (last modified time), while updating it from the IDE. If the timestamp does not change, you should check your compilation settings in the IDE. Also make sure that the monitored folder is the same as the IDE output folder.

  • Does the reloaded code get re-executed? Keep in mind that some parts of your application code are executed just once. When you are changing a constructor or initializer method on an already created object, chances are that it will not be run again. Even if JRebel does reload the class, this will not reflect in the application until that component is recreated.


I checked everything and it still does not work!

Try searching the forum. You also have a direct line to the development team via the IDE plugins – open Help > JRebel > Submit a Support Ticket.

You can also email us. Let us know and we will be glad to help you with your issues. A good idea is to include a zipped jrebel.log when writing to support (refer to sending logs for help), because 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.