Jack Shirazi has written an article called "Hotpatching A Java 6 Application," pointing out how a process can attach to a VM and reload a class without restarting the VM or dropping a classloader. The article walks through a debugging session, a very simple example involving dumping a stack's contents. This may have limited applications for most developers, as they're likely to redeploy or restart the VM to apply changes, but the implications for application server vendors are intriguing: could this be used to hotpatch an application server to fix problems in the server code, or to allow dynamic reloading of end-user application code without special classloaders being involved?

"...basically you can change the code but not structure, hierarchy or method interfaces." In the context of webapps, how is this different than hotswapping today? If this is the best that Sun can come up with, after hearing the masses say they want faster and dynamic development, then I am a little disappointed.

Hi Matt, Can you tell me how many enterprise production applications you know that have hot deploy turned on by default for web or enterprise applications? I am finding it hard to recall an actual site that used such capabilities. Most sites of a reasonable size have good IT management processes and tools, and appear to favor complete JVM isolation for each applications/service with restarting of the service process the preferred approach to dealing with incident management (goal = restore normal service operation as quickly as possible). Problem management (goal = determining the cause and resolution) which is what appears to happening in the article is usually (if at all) conducted off-line with diagnostics snapshots of various system and components collected state dumps. There is rarely time to attempt such an exercise. This process is typically performed by application management staff who are unlikely to be trigger happy ("write code first then think about what I am doing") developers willing and able to write a JVMTI agent. In my experience getting new software installed in production is a challenge even during the planning stages of an application. Getting an agent loading post the production deployment seems completely improbable from were I am standing. The true cost (time and money) is in the streamlining of the change management process that IT management place on project teams especially when today it is still not fully integrated any real and usable deployment solution. regards, William

Getting an agent loading post the production deployment seems completely improbable from were I am standing. The true cost (time and money) is in the streamlining of the change management process that IT management place on project teams especially when today it is still not fully integrated any real and usable deployment solution.

regards,

William

Not true at all. I built and used such an agent system in highly critical (hospital) environments using our own custom appserver based around Jini / Javaspaces during the whole ejb2 boom. It wasn't pretty the first couple times but eventually stabilized into a nice system that made building more and more automation of upgrades / debugging / etc exponentially easier over time. This wasn't an environment where servers being "down" at any time of day was ever really ok.

Not true at all. I built and used such an agent system in highly critical (hospital) environments using our own custom appserver based around Jini / Javaspaces during the whole ejb2 boom.

It wasn't pretty the first couple times but eventually stabilized into a nice system that made building more and more automation of upgrades / debugging / etc exponentially easier over time. This wasn't an environment where servers being "down" at any time of day was ever really ok.

I agree with (the other) William and would say that your example is an exception in larger organizations. Since 1998 - when I first began using what became part of J2EE - in large enterprises - financial services, insurance, law enforcement/national security, never have I seen any of my clients agree to anything resembling a hot deployment of code for enterprise apps. There have been cases when I've recommended it, but they were far too conservative to take the chance. William's (the other) take on it pretty much nails the thinking I've seen. BTW, we've also had hot deployment capabilities in other platforms - using dynamically linked libraries - and I have seen that allowed in production for enterprise apps either.

You've got me there. I don't know anything about all of your clients or best management processes n stuff. I'm just a developer and know I liked it / it helped me.

Not true at all. I built and used such an agent system in highly critical (hospital) environments using our own custom appserver based around Jini / Javaspaces during the whole ejb2 boom.

It wasn't pretty the first couple times but eventually stabilized into a nice system that made building more and more automation of upgrades / debugging / etc exponentially easier over time. This wasn't an environment where servers being "down" at any time of day was ever really ok.

I agree with (the other) William and would say that your example is an exception in larger organizations. Since 1998 - when I first began using what became part of J2EE - in large enterprises - financial services, insurance, law enforcement/national security, never have I seen any of my clients agree to anything resembling a hot deployment of code for enterprise apps. There have been cases when I've recommended it, but they were far too conservative to take the chance. William's (the other) take on it pretty much nails the thinking I've seen.

BTW, we've also had hot deployment capabilities in other platforms - using dynamically linked libraries - and I have seen that allowed in production for enterprise apps either.

You have to bet your boss is one of top developer first, or you should fix your product release process first. This is the way how developer think business process without business context. I bet that there won't be too many people will used it in production environment at all, just like J2EE hot deployment feature.

...

I agree with (the other) William and would say that your example is an exception in larger organizations. Since 1998 - when I first began using what became part of J2EE - in large enterprises - financial services, insurance, law enforcement/national security, never have I seen any of my clients agree to anything resembling a hot deployment of code for enterprise apps. There have been cases when I've recommended it, but they were far too conservative to take the chance. William's (the other) take on it pretty much nails the thinking I've seen.

BTW, we've also had hot deployment capabilities in other platforms - using dynamically linked libraries - and I have seen that allowed in production for enterprise apps either.

I would agree with William Childers (William I :) ) on this one... "Hot deployment" may be the exception in web/JEE apps, but high end to end availability and "hot patching" shouldn't be. Unfortunately, in too many cases the creativity seems to be on specifying the SLA so 'planned downtime' for application upgrades is not counted as impacting availability. Thats fine if your user base is 9to5 in the same timezone, and the app doesnt change all that much. But isn't OK for a lot of us. Like William, I had to implement a custom solution a few years back. Any progress is welcome, hot deployment isnt really a solution as a full redeployment takes far too long and impacts users. We should be setting the bar a little higher, theres a lot of old existing mainframe applications where stability, high availability and hot patching has been regarded as a given for decades. With SOA, an applications availability is often dependant on the SLA of other services, which has considerable implications ... just my 2 cents

There are many (valid) reasons that companies favor the shutdown/deploy/startup cycle over "hot deployment" or "hot patching" but probably the single most important is that most applications/services have a high degree of fault tolerance built into their deployment topology (clusters). With clusters being increasingly highly dynamic in terms of membership, SLA being defined at higher levels of abstractions (aggregation of multiple metric end point) and virtualization becoming more affordable and manageable the need for "hot patching" has been narrowed down to a small number of core components within any major IT architecture which have very a small change rate. Most IT management departments will look for least business sensitive time window for any proposed change and stager the change over a number of members within the cluster to ensure continuous availability of the changed service. Getting back to the article I do not see why an agent cannot already be pre-configured within a JVM with the possibility of deferred loading & initialization. What would be nice would be to have the ability to instruct (config) the JVM to load a particular agent based on a event (exception thrown) or state change (low memory) for the purpose of diagnostics prior to a possible service interruption. But even then most companies would prefer to have these agent loaded but partially activated collecting some level of monitoring data. This article highlights a lack of understanding of how most enterprise IT management departments perform incident and problem management. It is a demo for sharing amongst development centric friends who get off on "cool" features of a new platform that is still not widely available in production. The article does at least touch on one important need - the ability to on-demand inspect system & component state. But this can be achieved today in a much more efficient, extensible and manageable manner today. regards, William

The StackTrace tool from http://www.adaptj.com can be used to hotpatch classes in running VMs. Look at the redefine command. Creating an agent the way described in the article apparently won't work all the time because Class.forName() will fail for some classes. instrument().getAllLoadedClasses() can help in situations like this. Also the security manager of your application may not allow loading classes from different files. StackTrace disables the security manager during the time when the interpreter runs.