As we are nearing the 1.0 M3 release we need to make sure that it is no less stable than the previous one. And for that (and many other things) we need your help.

Here are some things you could do to help us:

• Try out the latest nightly build in your environment.
• Run the automated tests (which we will publish) in your environment.
• Contribute a test case for the a problem that you found (or just an interesting border case)
• Suggest an interesting feature or improvement.
• Patch an Open-Source project to work with JavaRebel or just have better turnaround time (e.g. configuration reloading).
• … and much more.

To be able to communicate with you we have opened a ZeroTurnaround Community Google Group. This group is not meant for support requests, but rather for discussing latest nightly builds, possible features and generally the direction that ZeroTurnaround will take. At the moment it is private so you have to subscribe to it before you can read the posts.

In fact we mean this group to be a forum where we can exchange ideas how to improve Java turnaround in general and not just our products. One of the main possibilities in that direction is to contribute patches to Open-Source projects that improve developer turnaround (reloading Spring configuration on-the-fly is the first that comes to mind). This part of our goals is completely non-profit and we plan to also set up a non-profit counterpart site for the purpose of promoting these goals (ZeroTurnaround.org).

Quite a few of our users have contributed small pieces of code that test reloading of some parts of Java classes. Some of them have discovered genuine bugs and we are working on fixing them. However there was also some confusion that we want to clear up.

If you want to write a small test for JavaRebel you have to be aware of the two following things:

• JavaRebel will not reload code of currently running method. All new invocations of the method (even concurrent ones) will get reloaded, but the code in a running method will not reload. This means that if you have a method with while (true) {/*body*/} the body will never reload since you never leave the method. This is not a restriction in any real application, but this does show up in the small tests.
• The second issue is more particular to JavaRebel — if all running methods are of the same class they might not get reloaded (this does not always apply, but may compromise your test). This issue may come if you have only one class (e.g. Main) and try to change a method inside the same class.

The recommended way to test JavaRebel is to make a separate Launcher class with a while loop and call a method test() in another class (e.g. Test) with it. If you want to test concurrency make a separate class for threads (inner or anonymous will be enough).

Since we received some complaints that Moneybookers is less than comfortable to use in United States we are putting up a direct credit card payment system. We expect it to be up next week. Sorry to all of you inconvenienced by this!

On a different note we have received a lot of feedback and bug reports and next release is going to be much stabler and faster (especially faster startup). Although 1.0-M3 is expected in mid-November we will put up nightly builds next week so that you could check if your issues are fixed.

Eclipse IDE was used in the JavaRebel installation and demo screencast. We have got requests on how to integrate JavaRebel with IntelliJ IDEA. Of course JavaRebel is IDE independent and it all comes down to the users choice. In this quick tutorial we will outline the settings that you should enable to take the most out of JavaRebel & Intellij IDEA.We will be using the latest stable version 6.0.6.

Currently it is not possible to debug applications from IntelliJ Idea that are using JavaRebel. The issue has been reported to JetBrains.

Use the following tips increase your productivity.

• Develop in exploded mode
  • Make sure that you don’t package modules as war/jar files
  • Set the output directory to the respected WEB-INF/classes
  • This is done via Module Settings -> Output and JavaDoc -> Output path
• Turn off application deployment
  • Settings -> Project Settings -> Compiler -> Deploy web applications to server after compilation
• Ease the compilation process
  • IDEA saves files when you compile them.
  • Make sure all dependent files are also compiled.
    • Settings -> Project Setting -> Compiler -> Honor dependencies on “Compile” command
  • Start using the default compile shortcut Ctrl-Shift-f9 or map it to ctrl-s.

Opening Module Settings

Setting Output Paths

Compiler Settings

Whooh, what a first day for JavaRebel (technically second, but still)! We have been preparing for this day for at least half a year and it was just as great as we imagined! Thanks to all of you who were first to play with it and especially to those who took the trouble to report the problems back to us!

So far a lot of you are enjoying the instant turnaround, while some had troubles either installing or using JavaRebel. We have several confirmed issues and are working on them. We also found a bug in the Sun JVM 6 Update N EA and reported it back to the vendor. Hopefully they’ll get that fixed as well before the release.

It’s been great fun programming JavaRebel and now it is even bigger fun to see it used.

Although JavaRebel is a commercial product we do support the open source movement by providing free licenses of JavaRebel to qualified Open-Source projects (as you may know we’re developing the open source Aranea Web Application Platform ourselves).

To request a personal OSS license please e-mail support@zeroturnaround.com with the following information

• Project name
• Developer name and e-mail
• Proof of association (link to a page or mailing list associating the developer with the project). This is not needed if the e-mail belongs to the project.

To request a committer license for all project committers a project leader or representative should contact us.

JavaRebel reloads changes to Java classes on-the-fly without redeploy or restart including new methods and fields. It is a generic solution that works for standalone Java applications as well as application servers. For the impatient: watch the demonstration screencast (~5 mins) and download!

Ever since HotSwap support has been introduced in Java 1.4 people have been craving for more. As witnessed by this bug in the Sun database and numerous other discussions changing method bodies was just not enough. Dynamic languages like Ruby were quick enough to capitalize on this lacking touting Java EE development as slow and cumbersome.

As time passed by people have tried to work around the limitation by reloading classes along with their classloader. However since this requires also to reconstruct the object state it will only work in a controlled and limited environment — e.g. that of a web framework like RIFE, Tapestry 5 and so on.

Just as many others we were working on a workaround. However instead of limiting ourselves to the facilities provided by the Java platform we devised a whole new approach. Using bytecode modification and a little bit of magic JavaRebel extends the JVM with ability to reload almost arbitrary changes to classes on-the-fly. This includes adding and removing both methods and fields and the only forbidden changes are to ‘extends’ and ‘implements’ clauses. Since all the existing object instances are preserved the application and server can continue running and code changes are immediately visible in the application.

Watch the demonstration screencast (~5 mins), read the feature list or just download JavaRebel from ZeroTurnaround.com and give it a try. Disclaimer: JavaRebel is commercial software with a free trial for 14 days and developer seat cost at 99$.

ZeroTurnaround is a spinoff of Webmedia, Ltd. that focuses on Java developer productivity tools. Currently we are developing JavaRebel, a generic Java class reloader, and JSP Weaver, an instant JSP interpreter.

Although we have already posted this video elsewhere, it actually depicts one of the JavaRebel code reviews made by Jevgeni and Toomas. Enjoy!

P.S. And yes we are the same team responsible for Aranea.

This release includes numerous improvements in features, compatibility and stability.

Thanks to all of the beta testers we managed to collect and fix a lot of issues and thus make the open beta possible. We now support six different application containers (not counting the versions) and two JVMs (Sun HotSpot and Bea JRockit). Of course these features are mostly transparent to the end-user as JavaRebel will just reload more changes in more environments, but that makes it all the more valuable.