Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Try JRebel 6 beta: Now without restarts when making hierarchy changes to superclasses


In our previous post on some of the long-awaited, upcoming features in JRebel 6 (coming later in 2014), we described how you will now be able to make changes to not only class, resource and framework files, but also IMPLEMENTED INTERFACES (something that wasn’t possible before). Interested in trying out JRebel 6 beta? Simply download the latest version of JRebel and then follow the instructions here for enabling JRebel 6 beta functionality (like changing Superclasses or implemented interfaces without restarting)!

When talking to developers, we’ve seen that one of the most common refactoring methods that they apply is extracting a superclass. Extracting shared attributes into new super classes means the existing classes receive new superclasses.

In case you didn’t know, Class Hierarchy in type systems is incredibly complex; and changing a superclass of an existing class on the fly is inherently even more complicated. There are a myriad of things that one needs to get right and I could spend a long time detailing all of them. In this instance however, I would like to focus on introducing a superclass to my app without having to restart to verify its functionality, using JRebel 6.

Further Abstracting

Let’s consider the following class hierarchy: an abstract class Vehicle is extended by the Ferrari class. The Ferrari overrides an abstract method from Vehicle.


I want to change the class hierarchy as follows: I wish to introduce a new class titled Car; Car will extend Vehicle,  Ferrari will extend Car instead of Vehicle.


This example is obviously fictional, but it nonetheless demonstrates a typical use case. Here’s an example of my source code:

public abstract class Vehicle {
 abstract void drive();
public class Car extends Vehicle {
 public void drive() {
   System.out.print("Beep! ");
// - version 1
public class Ferrari extends Vehicle {
 public void drive() {
   System.out.println("Ferrari: wrooom!");

We change the Ferrari class by replacing the superclass from Vehicle to Car. For demonstration purposes we will invoke a method from the new superclass Car by the subclass Ferrari.

// - version 2
public class Ferrari extends Car {
 public void drive() {;
   System.out.println(" wrooom!");

Right now, to test this situation it is sufficient to run a while loop where we invoke the drive() method:

Vehicle v = new Ferrari();
while (true) {;

What happens when you try to change superclass with JRebel 5?

Not a whole lot. At least, not without restarting. Changing the superclass of Ferrari from Vehicle to Car could not be handled by JRebel version 5. The user was notified about this sad, sad fact and JRebel printed the following line:

2014-07-30 10:49:21 JRebel: ERROR The Superclass of 'Ferrari' was changed from Vehicle to Car and therefore this class cannot be reloaded!

The IDE plugins display a similar popup to notify the user about the situation:


How JRebel 6 handles this situation…

JRebel 6 handles superclass changes seamlessly. Once we exchange the initial version of the class Ferrari with version 2 (see above), we will see the following: wrooom! wrooom!
2014-07-30 12:23:01 JRebel: Reloading class 'Ferrari'.
Beep! wrooom!
Beep! wrooom!

The changed class was reloaded successfully and the application redeploy was avoided. Right after that we see the new output generated by the program. Great success!

Try JRebel 6 and get this functionality…

The ability to change superclasses was a long requested feature in JRebel. Now that we have finally found a solution to this, I invite you to try it out: just enable the superclass reloading option in the IDE plugin settings…the instructions are here.