July 23, 2009

Java Web App Availability – Is it Critical?

Filed under: blog — David Booth @ 7:10 am


For some folks, when the app goes down for whatever reason, it means coming in early tomorrow morning.. but for others, it means,

“Mom, Dad, I’m so proud of you and happy for you on this, your 50th wedding anniversary — and I’m truly glad you brought me into this world, but since you raised me to be such a responsible and devoted member of society, you’ll understand me when I say, ‘I’ve gotta go — our app is down.’”

We’re wondering what % of apps out there are treated like this, and what teams do to ensure that they stay available, all hours of the day, no matter what time zone the users are in – so we’re asking 2 quick questions to get to the root of it.  Answer them here.  We’ll  announce the results, and give out 5 personal licenses of JavaRebel to winning respondents at the end of next week.

July 22, 2009

JavaRebel 2.0.2b or ‘no plan survives contact with the enemy’

Filed under: news — Jevgeni Kabanov @ 3:19 pm

When we released 2.0.2 we had put it through every test suite in our arsenal to ensure that it would thrive and grow up strong (especially after a month of testing in the nightly builds). As the gods would have it, reports started coming in that not everything was as blissful as we like it with the Spring plugin, so we quickly fixed it up and released 2.0.2a. Now, a week later, we’ve released a followup release — 2.0.2b.

The main reason for this is a bug concerning a combination of try-catch-finally and synchronized keyword, which would mess up exception handling in those methods for some people. It’s now fixed (see the post by Michael).

However, we’ve also got some more stuff ready, so we’re including it as a bonus:

  • The Velocity plugin is now included and if enabled will allow access to new properties/methods from .vm templates.
  • Performance Improvements re: reflection should solve some slow startup issues.

The fixes are:

  • Fixed a problem with try-catch not working properly
  • Fixed Spring plugin compiled with Java 5 in 2.0.2a
  • Fixed an issue with autoupdater and Java 1.4.
  • Fixed Eclipse not starting up with JavaRebel enabled (for Eclipse Plugin developers).
  • Spring MVC plugin wasn’t enabled by default.

Grab it while it’s hot!

July 16, 2009

Free JavaRebel for Scala users, ZeroTurnaround announces

Filed under: blog, news — Tags: — David Booth @ 6:40 am

About a year ago the ZeroTurnaround team decided to support the Scala community by providing a free license of JavaRebel to all Scala users. The licenses provided at that time have expired but we want to continue and improve our support.

Instead of a license that expires on a set date – you can get a license with your name on it that lasts a full year. After that, just re-apply and voila: you’ll have a new key in your inbox. Grab the license key here: http://www.zeroturnaround.com/scala-license/

For Lift folks, the free Scala version of JavaRebel is already included in the Lift Installer – just pick up a license key to activate it.

BTW in JavaRebel 2.0.2 we fixed the issue with nested expressions that came up on the Scala/Lift forums recently, so everything should be reloading – faster than this guy.

July 14, 2009

JavaRebel 2.0.2 Released

Filed under: news — Tags: , , , , , , , — David Booth @ 12:34 pm


JavaRebel 2.0.2 was released today, and with it we’ve got a few announcements:

  1. It’s time to find a new name for JavaRebel – check out “Renaming JavaRebel” to learn more.
  2. Our Java EE Containers: Heaven or Hell survey has received more than 1000 responses, and it’s still open.  If you haven’t answered the 3 questions, do so here — and check out the results here.
  3. We’re collecting quotes from people who are already using JavaRebel.  We’re happy to hear anything you want to share!  Send it here.

And now for the release itself. Some improvements almost demand a more significant update number than a x.x.1… or perhaps announcements of their own…  To that we say – You are absolutely correct :-)  Stay tuned.

JavaRebel 2.0.2 Improvements Include:

  • Property resource bundles now reflect the changes to the property files. This should work without any special configuration from your part, just change the property file and see the changes reflected in your application.
  • Startup performance improvements.
  • SAP NetWeaver 7.0 and 7.1 are now fully supported.
  • Resin 3.1, 3.2 and 4.0 are now fully supported.
  • Preliminary support for Google App Engine. It should work, but let us know if it doesn’t, we’re not quite ready to vouch for it yet.
  • Spring plugin is now considered stable and enabled by default.
  • Spring plugin will now refresh XML files even when no classes were changed and no Spring MVC is used
  • Spring plugin will now instantiate and initialize new singletons eagerly (even if they are not referenced elsewhere)
  • You can now use -Xbootclasspath install option with Java 5+ (it works better on some older JVM versions and JRockit JVM)

There’s also a ton of fixes in this release:

  • Directories defined in rebel.xml are now also case sensitive on Windows
  • Fixed a deadlock in resource lookup (could cause infinite startup on JBoss)
  • Fixed a problem with enums being “X is not an enum type”
  • Fixed an issue that caused “Class (x) was removed” messages
  • Fixed an issue with backslashes in include/exclude elements of rebel.xml
  • Fixed an issue that caused NullPointerException on JBoss 5
  • Fixed an issue with @Deprecated annotation and AspectJ
  • Fixed an issue that caused NoSuchMethodError on some (otherwise valid) reloads
  • Fixed an issue with wrong class redefinition causing e.g. problems with JBoss 5 (http://www.zeroturnaround.com/forum/topic.php?id=303)
  • Fixed an issue that caused DuplicateMemberException on Jetty
  • Fixed an issue in Spring plugin that could cause an infinite loop when reloading a bean

You can pick up the new version on our download page, by clicking the standard download.

Enjoy!

Renaming JavaRebel

Filed under: blog, news — David Booth @ 12:33 pm


To start: A quick announcement before the big one.

JavaRebel has broken its own revenue records 3 times in the last 6 months – We’d like to thank everyone who has picked up a license for themselves, their team, and their entire company.  We’re glad to see so many people interested in the quick productivity improvement that JR provides, and though we have a long way to go, it’s rewarding to see that we’ve contributed something valuable for a lot of people!

Unfortunately, we have a little potential hurdle coming our way….. in the form of corporate lawyers ;-)

Short story made shorter:  We have been asked to remove the word “Java” from “JavaRebel”. You’ve probably heard this story before, so we won’t get into it.

Nothing to see here folks, please move along

Nothing to see here folks, please move along

Anyone who knows what it’s like to come up with a name for an internal, open source, or commercial project, let alone a name for a child (personal favourites: Jermajesty, Kyd, and Blue Angel) knows how hard it can be. RE-naming something close to you comes with extra challenges of its own.

So, for a giant community experiment, we’d like to open up the renaming of JavaRebel to you.

Here are our top considerations:

  1. There are at least a few people out there who are already familiar with the name “JavaRebel”. We’d like to make the transition as easy as possible on them.
  2. Almost ALL the traffic to our site comes from people who have linked to us using the name “JavaRebel”, or from direct searches for “JavaRebel” or “Java Rebel”.

Some of our thoughts revolve around keeping the word “Rebel”, and others are more open. What do you suggest? Any ideas? Please submit your ideas here. If we go with your name, we’ll give you a lifetime license of JavaRebel.. err.. whatever we call it :-)

Here are a couple ideas to get things started:

  • JRebel
  • JayRebel
  • JadeRebel
  • KavaRebel (Kava means coffee in czech – coffee, java, get it?)
  • LavaRebel (goes with the whole HotSwap, HotDeploy type naming convention.. but hotter :-)
  • FireRebel
  • Liberica
  • LibeRebel
  • Rebel++
  • LymeRebel
  • RebelHQ
  • SpeedLoader
  • Espresso
  • Caffeine

Thanks! I assume this is going to be a rather painful process, but we’ll make it through with your help! (wow.. that sounds SO lame. If I was in highschool, I’d get beat up for that :-)

Muchas gracias,

Dave

PS – Thanks to Sir_Edw for the Santa / Secret Service pic

July 13, 2009

Survey Winners: Java EE Containers – Heaven or Hell?

Filed under: blog — David Booth @ 4:34 pm

Just a quick update: we promised that 5 people would win licenses of JavaRebel from our most recent survey, entitled “Java EE Containers – Heaven or Hell?”

Thanks to Felipe Gaucho, Grzegorz Duda, and Luca Morettoni for being our random number generators :-)

The winners are:

  • Andrew Hoffman
  • Mateusz Jancy
  • Hariprasad Manchi
  • Bill Gloff
  • Jiri Vitinger

Congratulations!

As a note: the survey continues… If you are not one of the 1000+ people who have answered the 3 quick questions, then go for it now.  We’ll give away another 5 licenses when we post the updated results!

July 2, 2009

Survey Results: Java EE Containers – Heaven or Hell?

Filed under: blog, news — Tags: , , , , , , , , , , — David Booth @ 11:18 am

These results are preserved for comparison, but see the later report for a full analysis of the completed survey.

Last week we asked a few questions regarding Java EE development, containers and redeploy and restart times. It was surprising to see how quickly people responded — I suppose it’s becoming a hot topic!

We had to draw the line for our analysis somewhere, so we took the first 700 responses and created the charts below. If there is a significant change in the number of responses, we’ll update these charts with new results. The 2 minute survey is still running here.  Feel free to fill it out if you haven’t already.

If you’d like to analyze the results for yourself, we have provided a copy of the data. This data may be updated as new responses come in. Email addresses have been removed from this data set.

We hope this info provides interesting insights into the world of Java EE containers and development productivity! Since we’re not professional surveyors there may be some flaws in the data and in our interpretation — so we mention some of them below, and you’re welcome to analyze the data yourself :-)

“Most Often Used Java EE Containers”

Most Often Used Java EE Containers (based on 700 respondents)

We asked, “What container do you use on your largest current Java EE project?”, which is slightly different than the chart title. Unfortunately, we didn’t clarify the difference between containers used for development and production, so answers here may be mixed – we’ll do better next time.

As usual, there was a long tail of answers. Any answer that did not receive at least 7 votes (1% of the total votes in the survey) was not put on the pie chart. The omitted containers were:

  • Tmaxsoft JEUS- 4
  • SAP NetWeaver- 3
  • Iona/Progress Artix- 1
  • zeus 4.x- 1
  • Sybase EAServer- 1
  • Impala- 1
  • Adobe JRun- 1
  • Jonas 4.x- 1
  • Assorted earlier versions of containers listed in the chart- 13

“How long is the average container redeploy + app restart?”

Actual question asked: “How long does it take to restart your container and redeploy your app?” Now, you would think that folks who answered “I never redeploy” in the next question would have had a challenge with this one, since, well… they never redeploy. Apparently they overcame that challenge. They may have answered randomly, or, if they are JavaRebel users, answered with the amount of time that it used to take to redeploy/restart, before they eliminated redeploys.

“How often do Java EE developers redeploy, per hour?”

How often do Java EE developers redeploy in an average hour of coding?

Actual question asked: “In an hour of coding, how many times do you redeploy?” Unfortunately, we made an error here. When choosing how many times you redeploy, folks who know for a fact that they redeploy exactly seven (7) times per hour faced a dilemma. Hopefully they were able to overcome this and err on the side that felt more reasonable to them: 5-7 or 7-10.

For the folks who answered, “I never redeploy”, we asked some of them how they did this. Responses were:

  1. “I’m not the guy that does the redeploys”
  2. “We develop on embedded jetty & activemq & atomikos in debug mode instead of nearly unusable target OracleAS. So of course we need redeploy or restart jetty as usual, but not the OAS.”
  3. “I’m in the very early stages of a project so a lot of out time is spent coding and testing without redeploying – typically I redeploy 3-4 times per hour”
  4. “We use JavaRebel and it’s awesome” – which led me to believe that I should have asked people if they use JavaRebel right up front, since that may bias the numbers somewhat.

Java EE Container Specific Productivity Information
For the next few container-specific charts, there is the potential for a slight error when it comes to Jetty, Oracle, and Caucho’s containers, for the simple reason that there were not a lot of people in our survey reporting numbers for them. Jetty was used by only 27 respondents, Oracle 20, and Resin had 10. With numbers like these it’s easy to sway results. Of course, the 207 results from Tomcat users isn’t a HUGE number, but at least averages are more accurate. Solution: more respondents. The survey is still live, here.

How long does container X take to redeploy?
How long is the average redeploy using a specific container

Does container X affect incremental development?
Average Number of Redeploys per hour of coding

We thought that containers that redeploy quickly would lead to more incremental development – and this was generally true, but there were exceptions.

Time spent on redeploys, per hour, with container X
How much time is spent on redeploys in an average hour of coding

Calculated like this:
Time spent redeploying in an average hour = Average number of redeploys per hour of coding x Average length of redeploy (see “How long is the average redeploy” chart).

Percentage of development time spent redeploying with container X
Percentage of coding time Java EE developers spend redeploying v2 update

Calculated like this:
Percentage of coding time spent redeploying = Time spent redeploying in an average hour of coding divided by 60 (mins)

“Annually, How much time do Java EE developers spend redeploying containers & restarting apps?” (in hours)

Annually How much time do Java EE developers spend redeploying containers restarting apps v2 update

We wanted to estimate this number quite conservatively, so we took the amount of time spent redeploying in an average hour of coding and added that up over a year, based on these assumptions:

  1. A developer rarely actually codes for 8 full hours per day. We should account for non-coding days, meetings, coffee breaks, foosball, email, twitter, etc. We assumed an average of 4 hours of coding per day, 5 days per week.
  2. We also assumed that some people get (and use) holidays and vacations, and have other reasons why they don’t code everyday. These reasons would a) reduce the amount of full weeks in the year, and b) reduce the average # of hours of coding per day. To account for these, we based a year on 40 work weeks instead of 52. Those 12 weeks should account for almost anything else you can throw in here to reduce avg weekly/daily coding hours. We figure that if you’re not coding 4 hours per day, 5 days per week, for at least 40 weeks a year, then you probably didn’t answer this survey. If we’re off here, or this is not conservative enough, let us know.
  3. It would be interesting to know what this costs, in terms of development team budget. You can estimate it for your team here.

Survey Round-up: We were impressed to receive over 700 responses so quickly and are curious to know what you think of the results!  To start – we’re curious about the folks who spend an average of 81 to 309 hours per year redeploying… Is this something that is considered acceptable in terms of development time used?

I don’t want to do anything TOO “marketingy” here, but I do have to mention that JavaRebel eliminates the need to redeploy in most redeployment situations (see Container Support and the Comparison to HotSwap and Hot Redeploy).  From these survey results, that looks like an an extra 2 to 8 weeks of development time per year, or reducing the time spent coding on a project by 3.8% to 15.4%.    <cough> And it’s easy on the wallet. Download the Free 30 Day Eval <endcough> (see Pricing if interested)

Ok, I mentioned it.  Let me know if I can improve this survey in any way.

Dave

Our Customers Say

“For the price, and for how easy it is to get installed and running in a developers’ environment, using JRebel is pretty close to a no-brainer.”

Jim Lesko, GT Nexus

Recent Tweets

RT @davetownsend: i may have said this before but #jrebel just frigging rules for developing #spring apps. FTW! 12 hrs ago

5 Article Series on Reloading Java Classes http://www.theserverside.com/news/thread.tss?thread_id=59657 3 days ago

RT @jteigen: #sbt + #jrebel + #lift + #intellij = Happy Developer 3 days ago

Olark Livehelp