Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Life outside the IDE

Coding in a parallel toolset has its perks -- freedom, for one

By Nathan Hamblen, JavaWorld.com, 12/18/07

Page 4 of 4

Reboot rebellion

Long have we labored under the regime of the 1.2 minute server bounce. As our development machines get faster, our applications find more elaborate ways to initialize themselves that eat up that advancement. In theory, the startup times are irrelevant, as we're supposed to have everything figured out long before we try to execute code or even write it. In practice, the application startup delay is a productivity disaster that rewards superficial coding errors with a recess from work, whether it's wanted or not.

One of the primary advantages of scripting environments is that a state of hobbled development is rarely needed and never glorified. But things in Java are not as bad as they're made out to be, or are allowed to be. An embedded or plugged-in Jetty server fully supports the HotSwap functionality built in to Java since version 1.4. Unfortunately the usefulness of this approach has been eroded, as a fuller embrace of object-oriented programming in frameworks like Wicket quickly runs up against the limitations of HotSwap. Where adding a method was once a major decision that would require updating UML diagrams and the approval of a lead architect, it's now something you do for a small UI component whose visibility you want to program. And that shouldn't mean reloading fifty ORM definitions.

Now it doesn't. JavaRebel, which can also run inside an IDE, brings better code replacement to a barebones environment than existed before there was such a thing as "inside an IDE." To use it, you run your application as you normally would, but with some extra parameters. If you find you need to change or add something, just rebuild. JavaRebel is watching the classpath, and will notice the changes and reload classes just before they are next accessed.

To facilitate configuration, set the environment variable JAVA_REBEL to the full path to the single JavaRebel JAR. Our :run task for Buildr can then be generically expanded, as shown in Listing 10.

Listing 10. Buildr task to run through JavaRebel

task :run => :build do
      java('example.MyApp', 
        :classpath => compile.classpath + [compile.target.to_s],
        :java_args => ["-noverify", "-javaagent:$JAVA_REBEL"])
    end

And with Maven, the easiest thing to do is run its whole builder through JavaRebel (as shown in Listing 11), since the exec:java task does not spawn a new VM.

Listing 11. Environment variable to run Maven through JavaRebel

export MAVEN_OPTS="-noverify -javaagent:$JAVA_REBEL"

Using JavaRebel, you can keep an application instance running as you write code and significantly cut down on full application reboots. Try starting this article's example application with either builder and then changing the form's addition operator to multiplication, as shown in Figure 4. JavaRebel can update the component even after it's instantiated, which is the case when submitting a Wicket form that has already been rendered. In many cases that's sufficient, though naturally testing changes to code that only runs during object construction requires going back through whatever sequence will newly instantiate those objects.

Figure 4. Reloading with the multiplication operator (click for larger image)

Mental arithmetic in a world of calculators

After considerable effort and the exploitation of a variety of tools, some of which cost money to use beyond a demonstration period, you have an environment that is comparable to an IDE for writing Java code. It's better in a few ways, but falls painfully short in others. Why bother?

Firstly, recall that the modern-day palace of IDE coding is built out of software sand. Most of the time it works great, but if a storm hits it on the wrong day you might have to explain why a crucial, simple fix took hours to code and test. With an external fallback environment, you can just leave your IDE closed if it decides to crash.

Secondly and more interestingly, a decentralized environment supports any underlying technology that the operating system supports. While IDEs struggle to keep up with the one or two alternative JDK languages to which they've decided to allocate resources, text editors support them all by default. As it turns out, languages that are less hindered by standards bodies incorporate exciting new features faster than IDEs can wrap them up in GUI packaging.

Consider Scala, a type-safe programming language with many modern features that can interoperate with Java. Despite valiant coding efforts, its Eclipse plug-in is still a ticking time bomb. But it goes without saying that Scala can be written in a plain editor; and, if you like syntax coloring, there are definitions for 19 editors waiting to be used.

Because Scala's syntax and coding norms tend to be easier on typing fingers than Java's, name completion is less of a concern. All of the techniques described so far, even JavaRebel class reloading, apply to Scala, as shown in Figure 5.

Figure 5. Decentralized workspace (click for larger image)

Scala isn't the only alternate language to explore, and ultimately that is the point. With a flexible environment primed and ready to go, changing languages is just a matter of changing file extensions.

Besides, a little more time outside the padded walls of integrated development environments could do all of us some good.

About the author

Nathan Hamblen is a career software programmer who codes primarily in Java. In his spare time he works on the Databinder toolkit for Wicket and writes Coderspiel, a programming Weblog.

Read more about Tools & Methods in JavaWorld's Tools & Methods section.