Frequently Asked Questions

• What is JavaRebel?
• What kind of classes does JavaRebel reload?
• When will JavaRebel reload classes?
• Why are there extra lines in the exception stack trace?
• Why does my IDE show an error “hot code replace failed”?
• Why do I get NullPointerException when accessing a newly added field?
• Why doesn’t JavaRebel reload the changes in the test I made?
• Why setting a breakpoint in debugger doesn’t work?
• Why can’t I evaluate some of the expressions in debugger?
• Why do I have trouble setting a conditional breakpoint?
• I think something is wrong, how do I report it?
• I get “Too many open files” message?

What is JavaRebel?

JavaRebel is a small JVM plugin (-javaagent) that will reload changes made to Java class files and thus increasing developers productivity and decreasing turnaround as for the changes to take effect no redeploy or restart to the container is needed. See the JavaRebel about page for more information.

What kind of classes does JavaRebel reload?

JavaRebel reloads individual class files by default (e.g. the ones in WEB-INF/classes. This makes it very comfortable to use incremental compilation available with modern IDEs and immediately see the changes in code in your application. JavaRebel can also reload classes bundled in JARs, WARs and EARs, to read more about it see the installation manual.

When will JavaRebel reload classes?

JavaRebel reloads classes lazily. This means that if you have (re)compiled a class file it will get reloaded once an instance of the class or the class itself is used - method call is made, field is accessed etc.

Why are there extra lines in the exception stack trace?

JavaRebel adds some generated classes and methods to allow for class reloading. To distinguish these methods them from the original ones in the stack trace we mark them as ““. The original file names and line numbers are preserved in the stack trace next to the original methods.

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

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

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

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

Why doesn’t JavaRebel reload the changes in the test I made?

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

Why setting a breakpoint in debugger doesn’t work?

Sometimes debugger will fail to set a breakpoint. To remedy this just change the file randomly (e.g. add a space in the end of the line). This will resynchronize the lines and class name between the debugger and JavaRebel and breakpoint will be set successfully.

Why can’t I evaluate some of the expressions in debugger?

Due to limitations in the Eclipse Java Debugger (among others) we had to alter the current instance “this” variable name to “that”. This means that accessing instance methods and fields directly will fail and you should use “that” instead:

getMySomething() -> that.getMySomething()
this.getMySomething() -> that.getMySomething()

Another problem is that Eclipse does not allow expressions accessing private members (fields and methods). The easiest way to solve it is to temporary change the access modifier to protected.

This means that in many cases just clicking on an expression in class text and inspecting it is likely to fail (if it refers to current instance or private members). What you should do is copy and modify it adding that in front.

An alternative solution to viewing expressions is to assign them to local variables in the class text and then watch the local variable:

String mySomething = getMySomething()

Same trick works for quickly viewing private members.

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
}

I think something is wrong, how do I report it?

If you think that you encountered a bug in JavaRebel and it has not been reported before in our forums please include the following:

• When and how did the problem appear
• Exception log (if there is any).
• JavaRebel.log obtained by adding “-Drebel.log=true” to the JVM command line. This is created in the same directory as the “javarebel.jar” and should be zipped before sending. The log includes information about your license, environment and the classloading information including names of loaded classes.

You can report the problem on the community forums unless it contains some sensitive information. In the latter case report to support@zeroturnaround.com.

In case you will be requested to send also classloading info you can refer to the Enabling Logging for Classloaders in Different Containers.

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.