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

Try JRebel 6 beta: Now change implemented interfaces without any restarts


Hey folks, before we begin we’re happy announce that our JRebel 6 beta program continues at a great pace and we’re getting some excellent feedback from a lot of early adopters. Want to be one? 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)!

One of the more common refactoring methods that developers apply is the extraction of an interface. Refactoring the existing class in this manner means that we are changing the list of implemented interfaces.

There are a myriad of use cases where it is applicable to change the list of interfaces implemented by a class. In this blog post I would like to focus on the new ability in JRebel 6 by demonstrating it with a simple example.

Refactoring Interfaces

Imagine finding a method written long, long ago by some other developer. A very common situation would entail this method receiving a class as a parameter. Your hands are surely itching to fix the method so that it receives an interface instead of a concrete class implementation. But then you realize, DANG, the class used as a parameter for that method doesn’t specify an interface. You would need to extract an interface to decouple the implementation.

Let’s assume that the method we are talking about is process() and that it takes the Gadget class as a parameter:

public void process(Gadget gadget) {

public class Gadget {
  public String getName(){
    return "Gadget";

Now the assumption is that the method could receive different class implementations that share one common method, getName(). So let’s introduce a new interface named Item:

public interface Item {
  String getName();

The new version of the Gadget class would appear as follows:

public class Gadget implements Item {
  public String getName(){ return "Gadget"; }

And the method that receives it as an argument:

public void process(Item item) {

The change spans the entire receiver method – we changed the argument type, but also the implemented interfaces of the Gadget class. Let’s look at this type of change with JRebel enabled.

JRebel and Implemented Interfaces

Changing the list of implemented interfaces for the Gadget class in the example above could not be handled by JRebel version 5. The user was notified about this sad, sad fact and JRebel printed:

2014-07-30 15:49:01 JRebel: ERROR Class 'Gadget' implemented interfaces were changed from [] to [Item] 
and could not be reloaded!

Have no fear – JRebel 6 handles this kind of change seamlessly!

Once we add a new interface to the existing class, for example:

Gadget implements Item

JRebel will reload the Gadget class and apply the changes:

2014-07-30 15:53:21 JRebel: Reloading class ‘Gadget'.

Great Success!

In Conclusion

The ability to modify the list of implemented interfaces gives you even more freedom when refactoring your code, all without having to restart your application with JRebel. You can give it a try by enabling the superclass reloading option in the IDE plugin settings – read the instructions here.