Screencast: Developing Swing with JavaRebel
Thursday, June 12th, 2008We start by launching the application with “-noverify -javaagent:javarebel.jar” added to the VM params in the Eclipse launch profile. We first add new field “BCC”, which immediately appears in a new window. We then also add a Send button, which first does nothing. We then proceed to add a listener that points to the new send() method. After we make the body of the method to show a message box it is visible in both new and old windows that had a listener added. Finally we refactor the class adding a field and showing its value in the message box. Note that old instances have the field, but it’s initialized to null, while the new instance works properly.
Since most of the Swing initialization will happen only once, a nice trick we found for making a component reinit itself is using the JavaRebel SDK as follows:
new ClassEventListener() {
public void onClassEvent(int eventType, Class klass) {
if (MyClass.class == klass) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
reinit();
}
});
}
}
});
Zero turnaround with unexploded development
Friday, April 11th, 2008In this article we will look at how to setup the development environment to support unexploded development. We will take the Spring Framework sample named PetClinic. We will deploy this to JBoss as a WAR archive and then start modifying the classes in Eclipse IDE and see the changes on-the-fly from the browser.
Before we continue lets look how it works. Once an application is deployed to the container (in this case JBoss) it will start loading the application classes. JBoss is running the JavaRebel agent that will intercept the calls and load those classes from the preconfigured IDE output directory.
Note however, that this means that if a new class is added in the IDE but not present in the JAR files, the JAR files needs to be updated. Why? We are still talking about the classloaders of the container. Container only knows and looks for classes that are present in the EAR/WAR/JAR files and these zip archives are cached. So adding classes still requires the redeployment of the zip archives.
The normal development model in unexploded development looks like this:
- Code modifications
- Build the archives
- Update the EAR/WAR/JAR in the container
- Restart the container or redeploy the application
- Check the modification
We will change this into:
- Code modifications
- Background compiling
- Check the modification
We assume you have downloaded the Spring Framework (in this case the version number is 2.5.3) and created a Java project from the folder spring-framework/samples/petclinic. We have enabled the IDE to build automatically the source files. Eclipse will by default start building classes to the spring-framework/samples/petclinic/.classes folder.
Lets build the WAR archive. Open up a console and change directory to spring-framework/samples/petclinic. Issue the command ant warfile. It will produce a petclinic.war in spring-framework/samples/petclinic/dist. Copy this file to your JBoss’s deploy folder.
Start the database server for the application. Open up a console and change directory to spring-framework/samples/petclinic/db/hsqldb/ and issue the command server.sh (on Linux) or server.cmd (on Windows). This will start the database server. You should see something like this:
[Server@8813f2]: [Thread[main,5,main]]: checkRunning(false) entered [Server@8813f2]: [Thread[main,5,main]]: checkRunning(false) exited [Server@8813f2]: Startup sequence initiated from main() method [Server@8813f2]: Initiating startup sequence... [Server@8813f2]: Server socket opened successfully in 4 ms. , alias=] opened successfully in 259 ms.0, db=file:petclinic [Server@8813f2]: Startup sequence completed in 268 ms. [Server@8813f2]: 2008-04-10 16:00:59.471 HSQLDB server 1.8.0 is online [Server@8813f2]: To close normally, connect and execute SHUTDOWN SQL [Server@8813f2]: From command line, use [Ctrl]+[C] to abort abruptly
Now lets add a configuration option to the JBoss startup script. We presume you have already installed JavaRebel. We will modify the JBoss/bin/run.sh (on Linux) or JBoss/bin/run.cmd (on Windows). First lets find the full path of the folder that your IDE is compiling the classes to. In my case it is /home/demo/projects/spring-framework/samples/petclinic/.classes. Lets add this as a Java -Drebel.dirs option to the JBoss startup script. So JBoss will have the flag -Drebel.dirs=/home/demo/projects/spring-framework/samples/petclinic/.classes on startup in addition to the usual JavaRebel flags. See JBoss installation for details on modifying the startup scripts.
Lets start the server. As the petclinic.war has been copied to the deploy folder, JBoss will deploy the application on startup. Depending on the server port visit http://localhost:PORT/petclinic. You should see the petclinic application homepage.
Now lets verify that everything got configured correctly. We’ll make a modification to a Petclinic class and see the output. We’ll test this by changing the validation of adding owners. In the browsers naviagate to “Find Owner” » “Add Owner”. Click “Add Owner” without filling any of the fields. You will see a page where it is stated that all fields are required.
Open the file org.springframework.samples.petclinic.validation.OwnerValidator in your just configured IDE project. We will modify the validate method. You will see validation rules:
if (!StringUtils.hasLength(owner.getFirstName())) {
errors.rejectValue(“firstName”, “required”, “required”);
}
if (!StringUtils.hasLength(owner.getLastName())) {
errors.rejectValue(“lastName”, “required”, “required”);
}
if (!StringUtils.hasLength(owner.getAddress())) {
errors.rejectValue(“address”, “required”, “required”);
}
if (!StringUtils.hasLength(owner.getCity())) {
errors.rejectValue(“city”, “required”, “required”);
}
String telephone = owner.getTelephone();
if (!StringUtils.hasLength(telephone)) {
errors.rejectValue(“telephone”, “required”, “required”);
}
else {
for (int i = 0; i <telephone.length(); ++i) {
if ((Character.isDigit(telephone.charAt(i))) == false) {
errors.rejectValue(“telephone”, “nonNumeric”, “non-numeric”);
break;
}
}
}
}
Lets remove the last name, address and city validations. The method will look like this now:
if (!StringUtils.hasLength(owner.getFirstName())) {
errors.rejectValue(“firstName”, “required”, “required”);
}
String telephone = owner.getTelephone();
if (!StringUtils.hasLength(telephone)) {
errors.rejectValue(“telephone”, “required”, “required”);
}
else {
for (int i = 0; i <telephone.length(); ++i) {
if ((Character.isDigit(telephone.charAt(i))) == false) {
errors.rejectValue(“telephone”, “nonNumeric”, “non-numeric”);
break;
}
}
}
}
Now when you click “Add Owner” button again you will see that the requirement for the last name, address and city are gone now.
You should also see the line JavaRebel: Reloading class 'org.springframework.samples.petclinic.validation.OwnerValidator'. in JBoss server log.
If the validation rules have been reloaded, you have successfully configured the unexploded development format. You have deployed a WAR file and made the container aware of the location from where to find the modified classes.
If you have multiple locations to look for the classes you can specify a comma separated list of location to the -Drebel.dirs option.
If you have any comments, suggestions or questions don’t hesitate to ask either in the comments section or via support at zeroturnaround dot com
JavaRebel Tutorial - Tomcat & Windows
Thursday, April 3rd, 2008Everybody does not have a standard installation of a JEE container and a development environment. As JavaRebel installation is a matter of adding -javaagent:path/to/javarebel.jar -noverify flags to the JVM, it can always be installed but exact configurations differ from one development environment to another. Rob Sinner has documented how he configured his environment on Windows running Tomcat as a service to support zeroturnaround with JavaRebel.
Developing in Exploded Format
Monday, January 28th, 2008We have had quite many support requests on how to use JavaRebel in different configurations. Either users have one Eclipse project from which they deploy three applications or the other way around, generating one project from multiple projects. Standard approaches (at one point copying or zipping into one archive and deploying) are quite slow in these circumstances and only provide a way to distribute the application and do not concentrate on how to make the developers’ work hours more productive.
In this article we will look at different configurations and see how to configure projects so that we do not spend too much time on building and deploying but developing the applications.
Sample Configuration
We will be developing a web application named WebApp and an accompanying library called OurLib. The WebApp depends on OurLib and we want to take advantage of exploded format in development.
Folder structure
WebApp/
src/- Source files with top level package combin/- Eclipse build folderlib/- Buildtime & runtime librariestests/- Tests’ source filesetc/- Configuration filesdist/WebApp.war- Distributable artefact generated by build cycle.dist/WebApp/- Distributable artefact before packing generated by build cycle.
It is better to use a more logical folder structure for web applications. One that has an application folder that can be deployed straight to a container. Then it is easier to separate buildtime and runtime dependencies and limits the need of constructing a special distributable folder during build. In this article will use the given structure though.
OurLib/
src/- Source files with top level package orgbin/- Eclipse build folderlib/- Buildtime & runtime librariesetc/- Configuration filesdist/OurLib.jar- Distributable artefact
Configuration
We will be deploying the WebApp to a Tomcat web container and Weblogic Server 9.2 . OurLib has to be accessible from the WebApp . We will be using Eclipse for development, Apache Ant as a standard building tool and the developers will be using either Linux or Windows (NTFS filesystem) environment. Eclipse is configured to build files automatically (from the Eclipse menu Project » Build Automatically is checked).
Typical Building
OurLib has a build.xml with target dist. It will produce a single JAR file in the dist folder. The target compiles the source files with the necessary flags, attaches the configuration files and archives into a JAR file.
WebApp has a build.xml with target dist. It will produce a single archive, in this case a WAR file. Consisting of the compiled class files, configuration files, static pages and so forth.
The OurLib.jar ends up in dist/WebApp/WEB-INF/lib either by WebApp’s dist target (has configured the OurLib location) or by OurLib dist target.
The WebApp.war ends up deployed in both application servers. This can be achieved manually (in WebLogic it is dozen of clicks) or automatically through the WebApp build script.
Developers perspective
On every deployment the following tasks happen:
- Source files are built
- Longer approach but universal:
javactask is invoked to compile the source files - Usually quicker: IDE’s output folder is used
- Longer approach but universal:
- Built files are aggregated into an archive
- Involves copying of files
- Files are zipped into a single archive
WARarchive is deployed- Archive is copied to the container’s folder
- Archive is unpacked to a temporary folder
- Deployment of the temporary folder.
As we can see there is just too much overhead from doing repetitive tasks that we can avoid. I did not include the steps that need to be taken to build the OurLib project or deployment to the other container too. We are compiling code twice, we are packing and unpacking an archive, we are copying files from one location to another, we are losing the session in the web application. Hopefully the deployment cycle is done through the build script. We would otherwise be clicking our way through endless dialogs to make the container understand how certain we are about the redeployment.
How long does it take? Depends on the size of the application. Probably from 30 seconds to some tens of minutes. Even 30 seconds stack up to a lot.
Exploded format
We can lose copying, packing, unpacking from the cycle in different ways. The main difference will be that we will start deploying an application as a folder instead of a WAR archive. To redeploy, one has to touch web.xml or hit Redeploy/Reload in the respected web interface.
With Weblogic deploying in exploded format is done the same way as deploying an archive. Instead of the WAR file you specify a folder. Weblogic will highlight a folder deployable if it has the WAR or EAR folder structure.
With Tomcat it is done by copying the folder to TOMCAT_HOME/webapps.
Application configuration
We need to produce the deployable folder from our project. The structure must be as follows:
WEB-INF/classes/- compiled class fileslib/- runtime librariesweb.xml
This can be achieved by making the build script create the folder structure, copy runtime libraries, compile source files and copy configuration files. The folder can then be deployed to a container. We could have structured the project to include such a folder
and keep the runtime libraries and configuration in such a folder structure already. This time we did not.
Next we will look at some examples of how we can configure the project so that seeing changes made to the source files will not require other operations than just hitting refresh in the browser.
Example
Eclipse is building class files to folder bin. We use dist/WebApp as the folder we deploy to Tomcat or Weblogic. We will use an ANT target that will makes the folder structure of the application (copying the class files from the IDE output location, lib files and configuration files to dist/WebApp respective folders). The very same target can be later used to zip the folder into a WAR file.
On every deploy we save the time of zipping and unzipping our project and depending on the configuration even the compiling. To deploy the application we click reload/redeploy in the application server.
Example With a Twist
We use a set of symlinks to completely lose the copying part and even invoking ANT. We will symlink the IDE’s output folder to dist/WebApp/WEB-INF/classes. The libraries will end up in dist/WebApp/WEB-INF/lib. Either the whole folder or just a subset of the libraries.
Now we have a configuration that requires no copying or invoking ANT. If we need to see the output in the browser we just have to redeploy the application. Now we are only losing the session in the application.
Example Without Redeploy
We will add JavaRebel to the equation and lose the redeployment part. As we are deploying everything as class files we can configure the server to use JavaRebel. See the installation documents for different containers.
Now we have a configuration that requires only a refresh in the browser to see any results.
What about OurLib?
OurLib can be deployed without zipping it into a JAR archive. The easiest way is to just symlink the IDE’s output folder to the WebApp’s deployment folder’s WEB-INF/classes. As we are probably already using a symlink for the WEB-INF/classes we have to make it a bit more granular. So for the WebApp we actually symlink, lets say, the toplevel package. So Webapp’s bin/com gets symlinked to dist/WebApp/WEB-INF/classes/com and OurLib’s bin/org gets symlinked to dist/WebApp/WEB-INF/classes/org.
Now if we want to see changes made to the library that we are using in our WebApp we just make a change, save the file (Eclipse is compiling in the background) and hit refresh in the browser.
Summary
Achieving shorter turnaround requires the developers to know the tools available to them. Projects use very different folder structures, build scripts and have different type of dependencies. Still developers can make their life easier with a set of tools and a bit of imagination.
Eclipse
Compiling can be done in the background and the resulted class files can be used for deployment. This is a real time saver.
Custom builders can be defined that run before or after every build. They can be made to copy some deltas or touch configuration files or actually everything. Here is how you create a project builder Ant buildfile.
Different source folder can have different output folders. E.g. the project has different folders for source files and unit tests. They can be compiled into different folders. Project properties » Java Build Path » Source Tab » Allow output folders for source folders checkbox.
Symbolic Links under Linux & Windows
Projects’ location and structure differ from the deployment counterparts. They can even be in a 1-n relationship. This is where symbolic links come into play. One can link directories or files to other places on the filesystem thus keeping the data in one place but available to different applications. Creating and managing links differ for operating systems, they are even named differently. See Similar Concepts from Wikipedia symlink article for more information. Mind that symbolic links are not something that only Linux users have, Windows has them too (comfortable and secure managing of them requires a freeware application though).
JavaRebel
Developers don’t have to restart a container or redeploy an application to see their code change in action. Make a change, compile the code and JavaRebel will pickup the changes. See the screencast for more information.
Debunking JavaRebel Myths
Tuesday, November 20th, 2007
As JavaRebel matures and gets more and more into the spotlight we get the same arguments against it repeated again and again. It seems that it is hard for the skeptics out there to believe that we and not “insert your any huge company here” came up with such a useful and long needed invention. We decided to spread some light on the most outrageous claims out there.
Myth nr. 1: JavaRebel doesn’t do anything
Usually formulated as “JavaRebel just runs redeploy when classes are changed. My container already does that!” or even “It just compiles classes in a loop, a 3 line Perl script would do better!”.
The answer is simple: JavaRebel reloads compiled classes without redeploying the application. By reloading we mean that whatever changes you did to the code are instantly visible in your application. This is subject to some constraints (extends and implements changes cannot be propagated this way), but there is definitely no redeploying happening behind the curtain. All object instances are preserved, which means that your application just continues running. And as far as we know there are no comparable tools out there at the moment.
Myth nr. 2: JavaRebel just uses hotswapping/class redefinition
Nope. In fact although JavaRebel uses the “-javaagent” it does not use hotswapping for any of the reloaded classes. What’s more JavaRebel works fine on Java 1.4 where no hotswapping is available without tapping through JNI. It is not a simple hack/wrapper on top of hotswapping and uses an approach that would work even if there would not be any hotswapping in Java at all.
Myth nr. 3: Container/Framework/Application X already does this
Perhaps. There is a well-know approach for reloading “managed” classes that we have even documented some time ago. However it only works when the object graph can be completely reconstructed — for example it is serializable. This works for some classes in some frameworks (e.g. RIFE, Tapestry 5), but it is only limited to that. JavaRebel works on all classes, all objects, always. You don’t need to worry, which code are you changing, it will always get reloaded.
JavaRebel Boosting Eclipse Plugin Development
Wednesday, November 14th, 2007Update: the Eclipse support has made it to the final 1.0 release of JavaRebel and development snapshots are not needed to use JavaRebel for Eclipse plugin development.
JavaRebel’s latest development snapshot includes support for the Eclipse Platform. The speedup that we can see with JEE servers when using JavaRebel applies also to other containers. In this case it is Eclipse. Developers can launch their plugins and as they change the source code they can see the results without restarting the new Eclipse instance.
We’ve prepared a small screencast (~5 min) that shows JavaRebel in action speeding up Eclipse plugin development.
The Camtasia Studio video content presented here requires JavaScript to be enabled and the latest version of the Macromedia Flash Player. If you are you using a browser with JavaScript disabled please enable it now. Otherwise, please update your version of the free Flash Player by downloading here.
Configuring JavaRebel for Eclipse is as easy as adding VM arguments -noverify and -javaagent:path/to/javarebel.jar and launch as usual as a Eclipse Application Configuration.
JavaRebel Integration and Custom Class Loaders
Tuesday, November 13th, 2007The functionality described in this article is available at the moment only in JavaRebel nightly builds.
One of the main problems that comes up with JavaRebel is compatibility with a multitude of platforms for application development. Just recently we implemented support for Orion, Resin and Eclipse, with many more awaiting our attention. The main reason for this is that to reload the classes we first need to determine where they are located on the file system. The only place to get such knowledge is the classloader, which does the actual resolving. And different classloaders may do that differently — therefore the trouble in supporting them all.
However in some cases integration should be easier. Specially, many custom classloaders will just inherit from URLClassLoader and delegate the actual loading to it. Other classloaders will override some of the logics, but provide the correct location of classes on the file system via getResource() URLs with “file://” protocol. We have implemented generic support for both these cases and will review the necessary steps here.
The following steps will currently only work with Java 5 installation mode (”-javaagent:javarebel.jar -noverify”).
Step 1: URLClassLoader support
So what do you need to do to enable generic support for URLClassLoaders? Absolutely nothing! If this is the case your application (or server, or platform) should just start working and reloading those classes. We have tested this with Tomcat and Jetty, which both feature URLClassLoader derivatives and it works like a charm.
Step 2: Custom class loader support
So what if it doesn’t “just start working”? This means that either your classloader isn’t a derivative of URLClassLoader or it does inherit some functionality, but overrides the critical one. For this case we have another trick up our sleeves.
First you need to determine the class name of the classloader in question. The easiest way to do it is put the following line in any class that will be loaded by that classloader (e.g. in a web application case it could be a servlet class):
System.out.println(getClass().getClassLoader().getClass().getName());
This will print the name of the classloader class right out to the console. Let’s assume the name was “com.acme.CustomClassLoader”. In that case all we need to do is pass it to the JavaRebel agent like this:
-noverify -javaagent:javarebel.jar=com.acme.CustomClassLoader
Sometimes there could be several different custom classloaders and in such a case a comma-separated syntax should be used:
-noverify -javaagent:javarebel.jar=com.acme.CustomClassLoader1,com.acme.CustomClassLoader2,...
This should get most of the custom classloaders to work.
Step 3: Contact ZeroTurnaround
The features described in this article will work in most cases. However sometimes class loaders are trickier and we need to do some work to support them. As an example, both Orion and Resin were integrated using the generic methods, whereas Eclipse was not. The problem with Eclipse was that it features OSGi classloaders, which have an internal “bundle://” resource protocol and some work needs to be done to determine the actual files behind the resources. So if you find that no matter what you do you can’t get the classes to reload just contact ZeroTurnaround via support@zeroturnaround.com and we will be glad to help!
Testing JavaRebel
Wednesday, October 17th, 2007Quite 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).
JavaRebel and IntelliJ IDEA
Thursday, October 11th, 2007Eclipse 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
