Blog

Yes, it seems like we only stopped accidentally writing “2009″ a few months ago.

The last 12 months have been an intense, fast-paced period of excellent growth – in this time we:

• Went from only 6 team members to 15 now (expecting even more in 2011),
• Released several versions of JRebel (latest is v3.5)
• Made some serious headway on our new product, LiveRebel (due for release in only a few short months!)
• Attended a half-dozen events, sponsored even more and sent Jevgeni, our CTO, around the globe giving talks.
• Established an awesome, physical office in Prague, Czech Republic (pictures coming soon)
• Missed only a handful of scheduled flights and,
• Even got a little bit of vacation time in there (not without the smartphone, however)

So, from the entire team at ZeroTurnaround, best wishes for the New Year 2011!

***

We recently added a Lift plug-in to JRebel (available in nightly builds) to make Lift application development with JRebel an even more productive experience than before. There have been some questions on Twitter about what that better support actually means. Currently we do just one main thing: reinstantiate Scala singleton objects that extend certain Lift framework types such as LiftScreen, Wizard, RestHelper and MVCHelper.

The behaviour of those objects is in part defined at object initialization time, so changing the code that is run during initialization will not affect the running application as the objects were alredy initialized. The JRebel Lift plug-in reinstantiates those singleton objects after their classes are reloaded, so changes in initialization code are picked up.

This enables at least the following changes to be made without restarts:

• changing the fields in a LiftScreen
• changing the Screens in a Wizard
• changing serve { … } blocks in a RestHelper or an MVCHelper

Note: in some cases when making these changes, you may still run into the closure reloading problem, which JRebel can’t handle (yet).

For an example, lets look at the wizard in the Lift demo app.

/**
 * An example of a wizard in Lift
 */
object MyWizard extends Wizard {
  object completeInfo extends WizardVar(false)
 
  // define the first screen
  val nameAndAge = new Screen {
 
    // it has a name field
    val name = field(S ? "First Name", "",
                     valMinLen(2, S ? "Name Too Short"),
                     valMaxLen(40, S ? "Name Too Long"))
 
    // and an age field
    val age = field(S ? "Age", 0, minVal(5, S ?? "Too young"),
      maxVal(120, S ? "You should be dead"))
 
    // choose the next screen based on the age
    override def nextScreen = if (age.is < 18) parentName else favoritePet
  }
 
  // We ask the parent's name if the person is under 18
  val parentName = new Screen {
    val parentName = field(S ? "Mom or Dad's name", "",
                           valMinLen(2, S ? "Name Too Short"),
      valMaxLen(40, S ? "Name Too Long"))
  }
 
  // we ask for the favorite pet
  val favoritePet = new Screen {
    val petName = field(S ? "Pet's name", "",
                        valMinLen(2, S ? "Name Too Short"),
                        valMaxLen(40, S ? "Name Too Long"))
  }
 
  // what to do on completion of the wizard
  def finish() {
    S.notice("Thank you for registering your pet")
    completeInfo.set(true)
  }
}

When running the demo app with JRebel but without the Lift plug-in, adding a new screen to the wizard has no effect, because the wizard is never reinitialized. But lets enable the Lift plug-in (from Agent Settings or by adding a VM argument: -Drebel.lift_plugin=true) and when the app is running again, add the following screen to the end of the wizard:

  // we ask for the pet's favorite food
  val petFood = new Screen {
    val food = field(S ? favoritePet.petName + "'s favourite food", "")
  }

This should be now picked up, at least for new invocations of this wizard. Any existing invocations of this wizard that were started before the change will likely have corrupt state, though.

The support for RestHelper, LiftScreen and MVCHelper is similar, and I hope the above example is enough to give you an idea of what our Lift support does. I also hope we can make Scala and Lift development even better in future versions of JRebel.

Finally, we’d like to thank David Pollak for his input, which made this plug-in possible.

PS. If you didn’t know, we offer free JRebel licenses for Scala developers. You can apply here.

Question:

What happens when over 1000 Java developers all over the world compare their development environments?

Choose one:

a) An angel gets its wings
b) Our CTO Jevgeni removes a random piece of clothing
c) Estonia has a snow-free winter
d) They get updated results that over 40,000 people found useful last year!

***

If you chose (d), then you win! Our prize is Java EE Productivity Report 2011

See the results. Download the PDF. Get your hands on the raw data.

***

***

This is not a test.

Find out more about LiveRebel and how you can get it.

Before it’s too late.

***

Our newest product, LiveRebel, has been in development for a while now and we have gathered a ton of feedback. The latest beta release is stable enough that you can just take it, install it and run it. So we thought we’d give you a chance to try it out.

But hold on – I’m getting ahead of myself.

The first question you probably would ask is what is LiveRebel. Basically, it’s the first cousin of JRebel, but running in the production environment.

The current version applies live updates to your clustered application instantly – from your choice of web console, command line or through the REST API. As the Rebel engine has some limitations, it does a compatibility check before applying the upgrade, so nothing interferes with the application stability.

You can use the functionality provided by LiveRebel to rollback failed updates and to create a fast track for critical fixes, ensuring that your application is stable with maximum availability at all times.

I hope this is as exciting for you as it is for us! Just sign up here and you’ll get your download link right away:

In case you were not at Jfokus this year (come in 2011!) and missed Jevgeni’s quickie chat about  saving 3-7 development weeks a year by preventing frequent redeploys (eh hem, using JRebel), then see him here:

http://bit.ly/zt_JK_jfokus2010

Don’t forget the popcorn!

Whew, Devoxx. Awesome Event. Great people. Strong Beer. Head-achey.

After the third helping of delicious pommes frites (cannot call them “French fries” in Antwerp with a good conscience) and mayonnaise, it suddenly occurred to me that we would be lucky to leave Belgium without a heart attack.

Add to that the now infamous kwak beer (8.5% alcohol), served for drinking in a low-end chemistry set, we were lucky to make it on any form of transportation that wasn’t an ambulance.

Kwak – Bringing grown men to their knees since the 1700s

But other than that, Devoxx 2010 was a top-notch event. We gave out four-month licenses of JRebel to hundreds of people. We saw old friends and met some new ones, and then forgot who they were the next day because of the Kwak…

A lot of interested people came to see the brand new ZeroTurnaround booth and to tell us things about JRebel like, “I’m naming my first child JRebel”. Ok, not really. Here are some photos of the ZT team working their magic:

Yes, Randy is in fact sleeping in this photo

Cheers to EAS (Enterprise Estonia) for helping us put the whole thing together. Your funds are awesome!

Sneak preview of JRebel 3.5 – IDE pop-up to show you how much time you’ve saved using JRebel.

***

Just a reminder, our annual survey comparing Java development environments has reached 1050 respondents. We’ve got to close it down in only a couple of weeks, so come be a part of it in two ways:

* Add your input and compare development environments with other developers all over the world

* See the preliminary findings so far – you might be surprised!

***

The last few months were very busy here at ZeroTurnaround HQ in the cold and gloomy Estonia. We wanted to deliver something awesome to our users, before we fully switch to working on the larger things planned for the 4.0. To that effect we decided to address some of the long standing requests as well as make some improvements to deliver better on our promise of “All changes reloaded, instantly!”. Whereas the previous major release focused mainly on the Java EE standards, this time we put our attention to supporting various Open Source frameworks and tools.

Last month we ran a survey on development environments (which is still open, btw, feel free to take a couple of minutes and make your voice heard). In the preliminary results we saw that Spring is used in almost half the Java EE apps today, so it’s great to say the 3.5 improves your Spring experience by working better in applications without Spring MVC and with the new plugin for Spring WebFlow that reloads your flow configuration.

The new plugins for OSS frameworks include Tiles, Wicket, Lift and others. We reworked the JRebel core to better support the OSGi containers, like Equinox and Felix. We improved serialization behavior and reflection performance. Scala and Groovy are now officially supported with JRebel. A score of other improvements and fixes is available in the changelog as well. Whew, that’s a lot of things for one release!

Oh, and one more thing — for years one minor, but persistant, annoyance for our users was the extra frames in the stack trace that JRebel introduced. Starting with 3.5 JRebel no longer adds them!

Get it while it’s hot!

Last year, we published a report on turnaround time, tools and application containers in the Java ecosystem. Over 1300 Java developers ending up sharing info about their development environment, and over 40,000 people found these results helpful.

This year we expanded on that, asking more and better questions to give you better and more accurate information. This preliminary release of our data includes 946 responses that were analyzed to create this report. The raw data, including all calculations, will be made available for download when the final version of the report is issued in December 2010. We want to discover:

• What is more popular, Ant or Maven?
• What Java IDE is the most popular?
• What Java EE standards are used the most?
• Which Java Framework are most prevalent?
• What Java Container / App Server is used the most?
• How much development time is spent redeploying Java containers?

The survey is still live. It’s 6 questions (slightly different than those above), and takes 2 minutes. Take the survey.

Build Tools and IDEs – Setting the scene

We asked everyone to mark the tools they use for building applications. The only two build systems to receive more than 1 vote were Maven and Ant:



As you can see Maven and Ant are used almost equally and some respondents chose both. Clearly they are each useful in certain ways.

The IDE chart is more interesting:

Eclipse has emerged here as the clear leader (in terms of # of users at least), with only one-third of respondents using IntelliJ IDEA (#2) and Netbeans (#3).

Servers & Frameworks – Who are the popular kids at school?

Compared to the last year’s chart we see % gains for the open source containers. We can also see that Jetty and Tomcat have a bigger share than last year, while Glassfish is sliding a bit. Oracle Weblogic and IBM Websphere have lost a total of 8% of the market to the open source containers compared to the last year (according to this sample of developers at least. A larger sample = better results. Contribute here :) ).

As far as Java EE standards are concerned we have the following picture:

JSP keeps the throne as the most popular Java EE standard (along with Servlets and JDBC not present here). JPA is amazingly popular, having over a third of the market. EJB versions altogether have 39%, which would make them the most popular standard, but there’s likely some overlap between EJB2 and EJB3 users, so the total is likely a bit smaller.

Let’s take a look at the framework chart:

Spring and Hibernate are by the most popular and in fact are still used more than standards. However, as far as web frameworks go JSF looks like a popular choice with 24% of answers. Unfortunately, we haven’t separated Spring MVC from Spring, but it’s likely at least as popular as JSF. The rest of the frameworks hold a share of 10% or less (GWT is barely over that and is the third most popular).

Turnaround times – How does your environment compare?

This year we asked questions about the time it takes to redeploy the application and number of redeploys per hour. We also asked those who don’t have to redeploy to comment why this happens. We were glad to see the development in this area since last year – these were some of the responses we received:

• “I wait till I have enough changes to warrant a redeploy”
• “We use tests (unit tests, integration tests, etc)”
• “We use Eclipse/Sysdeo/Intellij IDEA/etc HotDeploy”
• “We use HotSwap/Eclipse Debugger Session/etc”
• “We use OSGi”
• “We use Grails, Play! or Tapestry 5″
• “We use JRebel” :)

(Commentary on these responses, provided by ZeroTurnaround Founder & CTO Jevgeni Kabanov, will appear elsewhere and in different forums).

We originally did not include a “30sec” answer to the question “How long does take to redeploy your application?” However, we have since received a few comments about that – and to compensate for that, we will use a “45sec” value for the answer “1 minute” answer. But you can see that 30 sec has since been added to the survey.

The first Turnaround question was “How long does it take to restart your container and redeploy your app?” The answers are distributed like this:

We didn’t ask with such accuracy last year, which makes it harder to compare, but it seems the trends have remained the same.

Last year’s average redeploy time was 2.5 minutes, and this year the average redeploy time is 3.1 minutes. But with a standard deviation of 2.8, which means that the redeploy time varies greatly. It can be noted that a statistically significant segment of respondents chose answers over 10 minutes.

The next question was “In an hour of coding, how many times do you redeploy?”:

The average frequency is 4 times an hour with a standard deviation of 3.2. Last year, our average frequency for redeploys was 5 times per hour.

To calculate the total time spent redeploying in an hour we first removed those who “don’t redeploy” at all and those that reported redeploying “more than 45 minutes” of every hour (woah!). Calculating the total we get:

Average respondent spends about 9.7 minutes an hour redeploying with a standard deviation of 8. This is about 16.1% of total coding time.

As with last year, we took the assumption that the average Java developer spends about 5 hours of every day coding. The other 3 hours of each day we assume are spent answering emails, having meetings, drinking coffee, swordfighting, and doing other tasks.

Taking into account this 5-hour coding day and 4 weeks a year of vacation [some get], we get about 4.8 work-weeks each year spent redeploying. So, even a lucky developer that gets 4 weeks a year of vacation time will spend on average even more time than that waiting for redeploys.

Finally, we can also see how the choice of container correlates to the time spent redeploying. Note that it doesn’t mean that bigger containers are that much slower, rather bigger apps influence the choice of container:

Compared to last year, not many application servers changed, with the exception of Glassfish v3, which is apparently faster than before.

Stay tuned for the final report in December. More good stuff (including analysis) to come.

Remember, this survey is still open and the more developers that come to share their Java environments, the better and more applicable our results will be! Did we mention that before? ;-)

I like the one in the brown bottle....

Hallo, Bonjour, Guten Tag!

Gonna be in Antwerp for Devoxx 2010? Come and meet face-to-face with ZeroTurnaround’s wizards, code monkeys and marketing droids behind JRebel!

Here is what you will get by visiting ZeroTurnaround at Devoxx:

• How to get JRebel for free (the many ways to do this)
• Live demos showing JRebel in the real world
• The preliminary results of Java EE Containers Part II: What’s Changed in a Year? (still open for input!)
• Java community sponsorship – why ZeroTurnaround loves this even more than a Star Wars marathon!
• A small area filled with sweating men – and no booth girls! (wait, our CEO says that this isn’t a benefit….)

In any case, hope to see you there!

Older Entries »