Zero Turnaround

You know you have ZeroTurnaround when you are able to make any change to your application and, the nanosecond you save your changes, you can see their effect in your running application.

This is one of the reasons those PHP or Ruby developers say that they are much more productive than Java developers; anyone that has had to wait 30 seconds to see an extremely simple change in the code (like from if(var=="value") to if(var.equals("value)) be redeployed in JbossApplicationServer knows that not having ZeroTurnaround redeployment can be a big time-waster, specially during development, but also in production, specially if keeping downtime to the minimum is a priority.

One company (with this name precisely) offers a product named JavaRebel that gives Java ZeroTurnaround capabilities, another option is using OpenServicesGatewayInitiative Framework (OsGi Framework), what I find dissapointing is that Sun decided to embrace OsGi (now named DynamicComponentSupportForJava) a complex technology that will require modification of the way .jars is packaged now, instead of plain just buying JavaRebel and making it OpenSource (or creating its own version of JavaRebel, after all if Sun invented Java, why they didn't come up wit this idea themselves? Would it really be that hard for them to create something similar?). -- AnonymousDonor

I think you have that backwards:

Sun wants to split the Java runtime into separate modules (jars) so that partial and incremental deployment are possible, and JSR 277, The JavaModuleSystem? enables them to do this.
- True
The other big need for OsGi / JavaModuleSystem? (JSR 277) functionality is to fix the ClasspathHell problem: My application uses libraries "B" and "C", both of which use library "D", but "B" and "C" require different versions of "D". There's no version of "D" I can put on the CLASSPATH that will satisfy both "B" and "C". Thus, I'm in "ClasspathHell."
- True Too
But you are forgetting the third goal , dynamically loading and unloading modules (a requirement for ZeroTurnaround) (as it is supported in the latest OsGi enabled application servers also such as JonAs or Sun owned GlassFish ) Or as it is possible thanks to SpringFramework in their new SpringSourcedmServer, or as it is theoretically possible in Eclipse (although not as stable as it should because Eclipse was not built with OsGi support from the start (and even then we would need a MultitaskingVirtualMachine to actually make it module crash proof) )

-- JeffGrigg & AnonymousDonorTwo, intermixed

I can see this leading to a "just hack it" mindset, since the time to see a change is so small, the developer starts to make changes instead of thinking about the correctness of said change. -- AnonymousDonorOne

Yes, it does, but I think that developers should avoid the "just hack it" mindset because of some kind of objective proof that it is actually better that the "design it carefully first", and not because the platform leaves them with no choice at all (See BondageAndDisciplineLanguage) -- AnonymousDonorTwo

Consider also unit testing and refactoring as well. -- AnonymousDonorThree

Please elaborate... -- AnonymousDonorTwo

Well, according to XP methodology practices, you are free to "spike" out a solution to a problem -- this is equivalent to hacking/cobbling something together.

Once things are working, however, you're now in a position to better understand the solution; either you can write your tests to back your hack (only do this if you know your finished solution matches the hacky solution, though), OR, you can rip your hack out, write your tests and follow proper TDD practices. In either case, refactoring (if at all possible) is encouraged.

You're using the hackability of the system to your advantage, instead of discarding it as a relic of bad behavior. -- AnonymousDonorThree

So... are we having some sort of ViolentAgreement? (We both think ZeroTurnaround is and advantage even if it can be abused by incompetent people) -- AnonymousDonorTwo

I don't know; that depends on whether or not you are the same person as AnonymousDonorOne, whose response I took in a decidedly negative context, not positive. All I'm saying that you don't need to discard thinking in terms of correctness when you make so-called "quick hacks." Hopefully I'm not being to violent in thinking this. :) -- AnonymousDonorThree

I am not the same person as AnonymousDonorOne I am AnonymousDonorTwo the one that loves ZeroTurnaround and apparently PeacefulyAgreesWithYou? ;-)

I find that when doing TestDrivenDevelopment (TDD) in ExtremeProgramming (XP), quite independently of doing SpikeSolution or not, quicker turnaround is always a good thing. The excessively long turnaround of JAR-ing and deploying code into a JEE application server, to be tested remotely makes TestDrivenDevelopment much more difficult -- even to the point of discouraging the use of TestDrivenDevelopment.

The most common and successful approach I've seen is to decouple the application code from such heavy dependencies on the server framework, so that the application code can be tested "outside of the container." Then startup and class loading issues largely disappear.

We should also remember that ExtremeProgramming's TestDrivenDevelopment style was developed in the SmalltalkLanguage development environment, which has always very dynamic: When a test calls a method that does not exist, the smalltalk debugger stops execution right there. Then you can add the missing method to the production code, pop the stack a few frames, and resume execution. So don't think that rapid turnaround necessarily implies hacking! -- JeffGrigg

See XmlForZeroTurnaround

FebruaryZeroNine