Blog

The Tools & Tech Leaderboard for 2012 shows…

We’re not much for fanfare here at ZeroTurnaround, but this is our most ambitious report that we’ve ever created. This year, over 1800 respondents shared their take on “the developer life” with us, with 1100 Java-focused surveys completed.

Want to know how much uptake Java SE 7 has seen since its release? Which IDE has grown most in user base since last year? Which application server has jumped 300% in popularity by Java developers since 2011? You’ll also get the latest numbers on Oracle WebLogic, IBM WebSphere, Eclipse, JBoss, Jenkins/Hudson, Maven, Subversion and Tomcat (alert: shameless SEO plug). It’s all in there!

In addition, we take a shot at questions like, “How do Java developers spend their work week?” and “What aspects of the coding life increase or decrease efficiency at work?” Sound good? Then sign up to get the full report!

Digging into data searching for insights is always an exciting activity. Last year’s Java EE Productivity Report 2011 was focused on tools/technologies/standards in use (exclusive selections) and turnaround time in Java (i.e. how much time is spent per hour redeploying/restarting).

This year, you will find in the full version of the Developer Productivity Report 2012 expanded coverage on technologies and tools used by Java development teams.

We also focused more on the abstract side of development. We wanted to know “What makes developers tick?” and learned a lot more about how the developer lifestyle. Our results include a lot of interesting trends and insights, so we broke them down into 4 parts:

• Part I: Developer Tools & Technologies Usage Report – coverage of Java versions, JVM languages, IDEs, Build Tools, Application Servers (containers), Web Frameworks, Application (server-side) Frameworks, JVM Standards, Continuous Integration Servers, Front End Technology, Code Quality Tools, Version Control Systems
• Part II: Developer Timesheet – How do devs spend their work week?
• Part III: Developer Efficiency – What aspects of your job make devs more/less efficient?
• Part IV: Developer Stress – What keeps devs awake at night?

Get the complete Developer Productivity Report 2012

It’s probably best to sign up to get the full Developer Productivity Report 2012, which includes the complete Developer Tools & Technologies Report, the Developer Timesheet Report, Developer Stress Report and the Developer Efficiency Report.

Not like you would hear it from us first, but IntelliJ IDEA 11.1 was recently released and we’ve released a new plugin for JRebel to match it: http://plugins.intellij.net/plugin/?id=4441

Ok, why do I need a new JRebel plugin?

The new version of IntelliJ IDEA has incompatible changes in the debugger API (http://youtrack.jetbrains.com/issue/IDEA-81452). It’s important for us that we maintain support and development for the older versions of IDEA as well. Unfortunately, this means we need to fork the plugin and present a new 1.4.x version for IDEA 11.1+.

Do I get anything with the new plugin?

Yes, this presents us with a great opportunity: we can now use all of the newer APIs that we previously did not for compatibility reasons. We will still support and develop the plugin for versions 8 through 11.0.2, but it will be version locked at 1.3.x.

We understand the possibility for confusion, but there are many positives for this as well. We can stop working with older APIs that we only used to maintain backward compatibility, and start using all of the new APIs that allow us to provide a better experience for our users. For example, now you can use the new “fancy file” dialog system, which includes autocomplete. Word.

How do I upgrade to the new JRebel plugin?

You need to first uninstall the existing JRebel plugin, as IntelliJ will natively install over the old version and try to use the same plugins. This won’t work, and the JRebel plugin will be disabled. Either uninstall the JRebel plugin through the Settings->Plugins window or delete the plugin in the USER_HOME/.IntelliJIDEA11/config/plugins/jr-ide-idea directory.

Then install the plugin again through the Plugins window in Settings (http://zeroturnaround.com/intellij-idea-jrebel-tutorial-formerly-javarebel/).

What if I want to keep using an older version of IntelliJ?

Even though the new IntelliJ version (11.1) installs on top of the previous one (11.0.x), you can still separate the configurations. Here’s how: copy the USER_HOME/.IntelliJIDEA11 directory to USER_HOME/.IntelliJIDEA111 directory. Now, you need to tell the new IntelliJ instance that it has to use the new location for the settings. This is done in INTELLIJ_HOME/bin/idea.properties file. The idea.properties file contains a number of parameters that point to the settings directory:

idea.config.path=${user.home}/.IntelliJIdea/config
idea.system.path=${user.home}/.IntelliJIdea/system
idea.plugins.path=${user.home}/.IntelliJIdea/config/plugins
idea.log.path=${user.home}/.IntelliJIdea/system/log

You just need to change it to this:

idea.config.path=${user.home}/.IntelliJIDEA111/config
idea.system.path=${user.home}/.IntelliJIDEA111/system
idea.plugins.path=${user.home}/.IntelliJIDEA111/config/plugins
idea.log.path=${user.home}/.IntelliJIDEA111/system/log

Now you will be able to keep 2 versions of IntelliJ with different set of plugins. This is a very specific case and hardly anyone would like to follow such a setup, but just in case, I wanted to let everyone to know that it is possible.

Why do Continuous Delivery supporters and Operations Teams love LiveRebel?

Operations teams love LiveRebel because it helps bring Continuous Delivery practices into reality, letting them sleep soundly at night. Far too often applications in production are updated manually at 3 AM by overworked operations staff, so as not to affect customer usage sessions. And if something breaks, LiveRebel was designed to bring high levels of automation and predictability to customers’ deployment pipelines, enabling them to commit production updates that are online, automated, transactional and 100% reversible via “panic button”. Plus, they deploy new versions during the day, with all staff available, in case something breaks.

What is LiveRebel from a technical POV?

LiveRebel is an application & server management solution that allows release engineers and operations managers to do online deployments of J2EE applications via hot updates, rolling restarts, or individual server cold starts. LiveRebel will manage the upload, version check, server update, load balancing, request redirection, and if necessary, server restarts required to get an application online as quickly as possible, with little or no user impact.

What are the top 5 things to know about LiveRebel’s features?

1. Includes installers for all major server environments (and a lot of minor ones too!), making it simple to manage your server with zero manual configuration.
2. Enables automated, transactional, reversible and predictable updates to production applications
3. Provides instantaneous hot updates to live apps
4. A 100% pure Java solution
5. Managed through a web-based GUI, with no local client required

What Application Servers and Cluster sizes does LiveRebel support?

LiveRebel 2.0 supports Tomcat, JBoss, WebLogic, WebSphere, Glassfish and Jetty (more coming soon). It supports server clusters of any size, or in the cloud: LiveRebel uses a kind of distributed load-balancing process, where each server is in charge of routing requests and sessions to other servers if necessary. In this way, LiveRebel can support very large server clusters and enable hotpatching and rolling restarts without interruption to user sessions – even for 1000 servers at a time.

How easy to install is LiveRebel?

You can download LiveRebel here: http://zeroturnaround.com/liverebel/current

After that, start it up and run a simple installation script that works with a supported application server and restart the container in the LiveRebel wrapper script. This takes just minutes, even on larger infrastructures (the LiveRebel installation script can be automatically downloaded from a central Command Center) and once you’re done all servers and applications can be managed directly. Instrumenting existing servers can be done with a simple restart, without impacting existing deployed applications.

How does LiveRebel fit into the Continuous Delivery / DevOps model?

LiveRebel will help automate your deployment pipeline, creating a transparent, online, transactional and reversible process for updating apps in production, in line with Continuous Delivery concepts. LiveRebel also includes a Hudson / Jenkins plugin that allows hot-deployment directly from continuous integration servers. In addition, LiveRebel is 100% scriptable, allowing easy integration of the LiveRebel server management system into existing environments.

What sorts of deployment strategies does LiveRebel support?

LiveRebel supports multiple deployment strategies, depending on the needs of the organization. The deployment manager can decide the best strategy:

• Hot update (Hotpatch) – Applications can be updated in realtime, without any impact on users. Sessions are preserved, database connections are preserved, the users never see the change happen.
• Rolling restarts – Sometimes applications need to be restarted. When this is necessary, LiveRebel can manage your restart by shifting load off the servers, restarting them, and shifting load back, all completely automated.
• Offline updates – Take a server offline, do the update, run your tests on it, and bring it back online.

Who can benefit from LiveRebel, and how do I get my hands on it?

Any deployment manager, systems manager, operations head, architect, QA manager – anyone who regularly deploys applications (and who is tired of manual deployments at 3 AM!)

Get started here: http://zeroturnaround.com/liverebel/current

Any questions? Let us know at liverebel@zeroturnaround.com

That’s pretty big news.  JRebel for free?

Now, you may be thinking,

“But how can a company that survives off of their JRebel revenue (and employs >25 people) release a free version of the productivity tool? It even won a bunch of awards (JOLT Productivity Award, JAX 2011 Most Innovative Java Technology, Estonian Innovation 2011, and one more we can’t talk about yet)! Is their management team totally crazy?”

Here’s some background:

• We want to make a major impact on the Java Industry.
• We’ve collected data that says ~17.5% of every coding hour is spent building and redeploying.
• JRebel eliminates the need to build and redeploy.
• It’s been reported that there are about ~9 million java developers globally.

Imagine if those 9 million developers code on projects for 5 hours per day, over a 20 day period. That’s 900 million work hours, in what vaguely represents a month of work. JRebel could save 153 million hours of wasted time, per month, if every java developer in the world was using it. That’s more than 17,000 years of development time saved, every month. But JRebel costs about $1 per developer, per day – so some people can’t afford it. We want to change that. For about a year now, we’ve been thinking about different ways that we could give away JRebel for free – with one caveat – we can’t cannibalize our revenue and bankrupt the company — after all, we’ve got customers to think about, support cases to handle, and lots of new features to add – if we can’t do that stuff, then we’d be letting a lot of people down, and no one wants that. So our thoughts were… do we release a free version of JRebel…

• …with a limited feature set? If so, how do we separate the features?
• …for a limited amount of time?  We already offer a free 30-day evaluation…
• …and ask for donations?
• …that is free for a certain audience?  If so, what audience?  Hmmm… maybe we’re on to something here….

Introducing JRebel Social

JRebel Social is free to use for non-commercial development, and the only thing you need to do to use it, is let your network know it exists, once per month. Simply login and register using your Twitter or Facebook account and then pickup your online or offline license keys. As icing on the cake, you can see how much time you’ve saved by eradicating redeploys (and builds) from your Java development process, on your personal dashboard. You need to Download JRebel 4.5 to connect to Social. Try it out, and let others know what you think: https://social.jrebel.com I’m personally curious to see what will come of the thousands of hours that JRebel Social will save for the Java industry this year.. feel free to let me know what you’ll do with the extra time!

Click me for details on the 4.5 release.

David

Oh PS — we’re hiring! Engineers & Developers in Estonia, Marketing in Prague, and a Sales Team in Boston. Feel free to email us at jobs@zeroturnaround.com or Join The Rebellion

Although this tutorial concerns the Tomcat container, exactly the same instructions also can be used for JBoss and Jetty containers.

Compared to other containers out there, the Tomcat web container is one of the fastest when it comes to startup and redeploy times. Still, in a survey we conducted, developers estimate spending 18% of their coding time (about 145 hours annually, per developer – somewhere between 3-4, full, 40-hour workweeks) waiting for applications to redeploy. JRebel eliminates the need to redeploy in 80% of situations, and it’s easy to get started. In the embedded video you can take a quick look at how coding looks when using JRebel.

Tutorial

In this tutorial we explain how to install and use it step-by-step. We assume that you are using Eclipse 3.x with Tomcat 5.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

Contents:

• STEP 1: Install JRebel
• STEP 2: Installing JRebel Eclipse IDE plugin
• STEP 3: Make a rebel.xml for your application
• STEP 4: Configuring the Eclipse WTP IDE
• STEP 5: Configuring the Eclipse IDE
• STEP 6: Success!

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

STEP 2: Installing JRebel Eclipse IDE plugin

The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.

STEP 3: Make a rebel.xml for your application

In order to do it’s magic, JavaRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).

If you use Maven you can use the JavaRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

In 99% of cases, you probably use one module per project. In these cases, the JavaRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:

Click on your project and pick Generate rebel.xml.

Repeat this for all projects that you’d like to update with JRebel.

If you’d like to use one rebel.xml for your whole team, start with the generated rebel.xml, then replace the absolute paths to your workspace with a system property. JavaRebel will expand expressions like “${myProject.root}” in rebel.xml to a system property that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject. This allows to you to use a single configuration for everyone and then customize it when starting the server.

STEP 4: Configuring the Eclipse WTP IDE

You may skip this step if you run Tomcat outside of the Eclipse IDE.

Open the Servers View and double click the Tomcat Server that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

Open Publishing and choose Never publish automatically.

It may seem strange to disable automatic publishing, but as JRebel will take care of updates from now on it would just slow you down.

Open JavaRebel Integration and check Enable JavaRebel agent.

STEP 5: Configuring the Eclipse IDE

Go to Window » Preferences and from there to Java » Debug » Step Filtering.

Check Use Step Filters, Filter synthetic methods, and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.

Now go to Project » Build automatically and make sure it is checked.

STEP 6: Success!

To check that the installation was successful, access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

• Eclipse Plugin Tutorial
• Installation manual
• Configuration manual
• Maven Plugin configuration manual