Two years have passed since the release of JRebel 6. Throughout this time, two JRebel agents have been available in parallel (JRebel Agent and Legacy Agent). Now that the new JRebel Agent has fully matured, we are making it the default. JRebel’s support for remote servers has also been significantly enhanced. In addition, we have updated integrations with many of the frameworks and application servers to support their latest versions.
When upgrading to JRebel 7 from a previous version, check out our upgrade guide.
The next generation agent
We have changed the default agent used under the hood. This new agent (now simply called JRebel Agent) was first introduced with JRebel 6 and it supports almost any change that can be made to a class file. The previous agent (Legacy Agent), has been deprecated.
One of the most significant features of the new JRebel Agent is the ability to change class hierarchy. Have you ever been in a situation where you needed a class to implement a new interface and were frustrated because you were forced to redeploy the application after the change? Well, we have good news, these times are over with the move to the new JRebel Agent. Besides changing what a class implements, the new JRebel Agent also supports changing what a class extends, for example allowing you to refactor your code by adding an abstract class as part of the hierarchy.
The JRebel Agent also improves on many of the features present in the Legacy Agent. Among these is the ability to now perform initialization of newly added static fields without rerunning the entire static class initializer. This means that adding a new static field does not alter the state of the existing static fields on the class — the state is preserved. A similar fine-grained initialization also applies to instance fields, where the JRebel Agent will try to initialize added instance fields that are assigned a value when declared.
In the ever-evolving Java ecosystem, more and more frameworks and JVM languages, including Java itself, are beginning to leverage the dynamic power of the
invokedynamic instruction and the type-safe reflection-like
MethodHandles. The JRebel Agent now supports both of these. With the JRebel Agent, any method or field added to a class can also be accessed with the appropriate
MethodHandle, maintaining the correct access checks and restrictions, just as if those methods and fields had been part of the class from the beginning — just like when using the reflection API.
For a limited time, the Legacy Agent will continue to be shipped as part of the distribution. This was done to ease the transition to the new JRebel Agent. In the future, the Legacy Agent will be removed from the distribution, and active support and maintenance will be ended.
For most users, this transition is automatically handled by the JRebel IDE plugin. In some cases where custom startup scripts are used to run your application with JRebel, it will be necessary to modify your startup script in order to use the new JRebel Agent. Please refer to the detailed migration guide.
Adding these improvements required us to drop support for Java 1.4 and Java 5 from JRebel Agent. You can continue using the Legacy Agent when you are forced to use one of these ancient Java versions. In this case, if the upgrade to JRebel 7 automatically switched you over to the new JRebel Agent, you can manually switch back to Legacy Agent.
More frameworks, more servers, fewer redeploys
For Spring, we have added support for reconfiguring dependency injection in non-singleton scoped beans. You no longer have to recreate your session and lose its state just because you added a new autowired property on a session-scoped bean.
We continuously keep up to date with new versions of frameworks and applications servers. Recently, we added support for major new application server releases including WildFly 10, WebSphere 9, TomEE 7, and WebSphere Liberty Profile 16. The Payara application server is now also fully supported.
We strive to ensure compatibility with all the major JVM vendors out there. In addition to Oracle, OpenJDK, and IBM J9, support for the Azul Zulu JVM has been added.
Good news for remote server and VM users
JRebel support for remote servers and virtual machines has been significantly improved. Our plugins for the major IDEs (Eclipse, IntelliJ, NetBeans) now share a unified approach to remote server management. You can set up your remote servers through a dedicated, central UI and associate them with projects as needed. Explicitly mapping projects to servers is available for Eclipse and NetBeans (IntelliJ support coming soon). Managing remote servers from a single place makes switching multiple projects from one remote server to another very easy. So if you like playing around with multiple VMs for deployment, JRebel has the support you need, right out of the box.
Thousands of additional man-hours have been invested in the product to make sure JRebel is the go-to solution for productive Java development. Try JRebel 7 today or upgrade from an earlier version! When you need assistance with the installation or upgrading to JRebel 7, be sure to reach out to firstname.lastname@example.org.