NullPointerException when accessing
a newly added field?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:
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.
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 the plugin directory and the plugin section in the faq.
JRebel is meant and licensed only as a development tool. If you're interested in using the same engine for production updates, check out LiveRebel.
JRebel's free download includes a fully featured 30-day trial license. If you think that 30 days is not enough you can ask for an extension from support@zeroturnaround.com.
The Corporate License is licensed to legal entities, including corporations, academical and non-profit entities. When purchasing, just specify the number of developer seats. This number limits the number of simultaneous concurrent employees that can use the software at the same time.
E.g. when purchasing a corporate 30 seat license the maximum number of developers cannot exceed 30. The license can be transferred to new employees from old ones, but once the number of users exceeds 30 you have to purchase more licenses.
Note, that the only limitation is the number of concurrent users, so you can have JRebel installed on as many machines as you like, as long as the user number is within the limit.
JRebel licenses are granted for one year and must be renewed every year.
A Personal License is meant for individuals. Unlike the corporate license it has two restrictions:
It can be used on any number of machines as long as you're the only one using JRebel on them.
JRebel licenses are granted for one year and must be renewed every year.
The Open source developer license is granted for non-commercial development of open-source projects. It can be requested here. We're happy to support folks working on open source projects.
Refunds are available within 30 days from purchase — with no questions asked.
Yes.
Yes.
JRebel installation involves registering the -javaagent (in Java 5 or later) and configuring your application. Please see the installation manual for details.
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.
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 installation manual for details.
If JRebel is installed successfully, the following banner should be displayed in the console or standard output:
##########################################################
ZeroTurnaround JRebel 2.0-RC2 (200903112032)
(c) Copyright Webmedia, Ltd, 2007-2009. All rights reserved.
You are running JRebel evaluation license.
You have 25 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.
##########################################################
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 product page.
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 product page.
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 the plugin directory and the plugin section in the faq.
No.
Yes. You can find out more about configuring your IDE to work better with JRebel in the installation manual, by checking the corresponding box in the Tools category.
Select your platform in the installation manual.
Check your IDE box in the Tools in the installation manual.
Check the Maven box in the Tools in the installation manual.
There are also some limitations that apply for small tests only. Please read Testing JRebel if you intend to try it on small tests.
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.
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.
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 JRebel and breakpoint will be set successfully.
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.
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
}
NullPointerException when accessing a
newly added
field?JRebel will always reload changes to the fields, however newly added fields will not always be initialized:
NullPointerException on access. Object
types will cause a NullPointerException when
dereferenced.. 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. JRebel 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 “