Ah, a new release! Always an awesome day: even though the real milestones have been passed, this is the first day that we’re announcing JRebel 5.2 to the public. Woot!
Between JRebel 5.1 and 5.2, we delivered 3 minor releases (5.1.1, 5.1.2, 5.1.3), spending a lot of time on improving existing functionality rather than adding completely new features; however, we still have some new stuff for you, here is the list real fast:
- Apache Camel – JRebel now supports reloading routes and endpoints in Apache Camel 2.10 without starting
- Spring Framework – JRebel can now handle Spring 3’s
- JDeveloper – JRebel extends full IDE support for JDeveloper, bundling the JRebel agent into the plugin
- Mustache & Thymeleaf – JRebel can now clean up internal cache with these two template engines
- IDE plugins and debugging – Totally reworked debugger integration now shows updates to classes in the expression editor
- Framework plugin updates – JRebel 5.2 includes any changes to the 48 different frameworks supported
- New Documentation – Last, but not least, we got new doc layout and interaction. Try it!
Our customers have been asking about ESB support in JRebel for a long time. There are plenty of integration frameworks and ESBs, like Mule or Apache ServiceMix, that could benefit integration with JRebel. However, the nature of those frameworks is quite complex and we weren’t really sure where to start.
Fortunately, some JRebel fans got started and approached us with the use cases and examples for Apache Camel. In JRebel 5.1.2 we added support for Apache Camel 2.8 and in the new release we have ensured it can be used for reloading routes and endpoints in Apache Camel 2.10 managed applications.
As you change the route definition in the RouteBuilder implementation and recompile the source code, JRebel will restart the route and the application will implicate the new functionality without restarting.
No release of JRebel can escape improvements in our Spring plugin, one of the most popular frameworks we support. In the last release, we made sure that JRebel can work with Spring 3.2 and now we focused on covering more corner cases in Spring configuration support.
With the release of version 3, Spring makes a strong bet on annotation-driven configuration, and there’s a huge variety of useful combinations for configuring the beans. In the new update of JRebel, we added more handling for
@Configuration annotated classes. Currently, JRebel will try to reload only the
@Configuration classes that have been changed.
N.B. One important limitation that you should be aware of is that if there are dependencies on that changed
@Configuration class, then these dependencies are not reloaded/reinjected.
JRebel is now available as a plugin for JDeveloper. If you are using JDeveloper for ADF application development, then this is the plugin you definitely will be interested in.
The current version of the plugin is compatible with JDeveloper Studio version 11.1.2.x. You can download the plugin from http://dl.zeroturnaround.com/jrebel/jdeveloper/
One you grab that, you will see a ZeroTurnaround logo in your IDE menu, and you’ll be able to “Enable JRebel” there.
Here are the main features included into the initial version of the plugin:
- Bundled JRebel agent, so you do not have to install anything in addition to the plugin.
- Automates generating rebel.xml. Includes specific handling for ADF projects.
- Native JRebel settings UI is implemented.
- Debugger integration is included into the plugin and enabled by default.
- Setting JRebel parameters automatically on server start.
Please note that this is the first version of JRebel plugin for JDeveloper and we consider it as a beta version rather than a stable release. (Read = please give us feedback and let us know what sucks/rocks about it!)
Once an object is used in a template for the first time, the information about the underlying class is cached and the template engine doesn’t know about the new attributes of the class…even if it is reloaded by JRebel.
To remedy this, JRebel now integrates with template engines in order to clean up the internal caches inside so that the information about referenced classes could be refreshed.
Eclipse, IntelliJ IDEA and NetBeans IDE plugins get refreshed with improved debugger integration
We’re really happy to announce that our debugger integration in has been totally reworked in the IDE plugins (JRebel’s NetBeans plugin users saw a big change in the UI for their IDE with the JRebel 5.1.3).
JRebel’s IDE plugins for Eclipse, IntelliJ IDEA and NetBeans are responsible for helping the debugger to understand that there are new lines of code available after a class has been updated with JRebel.
These plugins updates will reinstall the breakpoints on the updated classes and the new members of the updated class are now visible in the expression editor.
If you launch the application from your IDE, then JRebel sets the argument for you and you do not have to do it yourself.
Framework plugin updates
The Java ecosystem is very active and new versions of popular Java OSS frameworks commonly sprout up overnight. With 48 web and server-side frameworks supported, it’s more than a full-time job to make sure that JRebel is on track with these updates.
We already mentioned Apache Camel integration improvements above, but there is more. In 5.1.3 there was a long list of framework integrations that were updated. In JRebel 5.2 we added updates for EclipseLink, TomEE, Log4j and Guice plugins. See the changelog for the full list of changes.
Shiny New Documentation
For a while now, we’ve been asking some users for feedback regarding our documentation, and thus started the long process of revamping it. So please review our new JRebel documentation, which has been updated, restructured and restyled. Get a quick look at it here: http://manuals.zeroturnaround.com/jrebel.
If you have any questions or comments, please leave them below or tweet them @JRebel.