Had an IM conversation with Gavin on "Zero turnaround Java". Basically the idea centers around a development turnaround time closer to that of PHP. I thought about a few things of how we could be as Zero-Turnaround as possible. Here is a breakdown of possible tasks/features we could do step by step: * A real "redeploy" event that reuses the DeploymentUnit/Context. In this case deployment metadata could be reused if metadata sources (.class or .xml files) have not changed on disk within the deployment. To make this happen, the deployment unit is going to have to remember all sources of metadata within the deployment. EJB for example would be a set of ejb-jar.xml, jboss.xml, bean class (and superclasses) as well as business interfaces as all these things are sources of metadata. * This point makes me wonder if the *redeploy* event should pass a list of changed files within the deployent unit path. * Hot Swap is useless. Yes it is neat, but since schema changes aren't allowed, its not going to cover 100% of cases. IMO, any Zero Turnaround solution needs to cover 100% of use cases otherwise there will be a lot of user confusion when things go bad. * Since Hot Swap is not viable, we will need to create a new classloader on redeployment to load changed classes. I'm guessing we can greatly speed up classloading on redeployment if we cache resources. The idea is that a classloader has a resource cache, on redeployment, the ClassLoader of the DeploymentUnit hands off its resource cache to a newly created ClassLoader. This way the new ClassLoader does not have to go to disk to load the .class file and can just get things from memory. Not sure how much this would speed up things, but this idea can be used for my next point. BTW, I think running in a debug session of most IDEs would allow for non-schema based code changes are runtime anyways. * When I've used PHP or another scripting language, the coolest thing for me was that there was no build/compilation step and you had WYSIWYG development as the source files were directly in your deployment path. I think we can do the same for Java. The idea would be to have a ".java" based ClassLoader. When a class needs to be resolved, the ClassLoader would look in its classpath for .java files or look in a memory cache for compiled bytecode. I took a look at Eclipse's JDT, the compiler that Tomcat uses to comple JSP source. Its pretty cool. You have total control on where to resolve source and bytecode when compiling something. A scanner would watch all ".java" files within a deployment. If one changed it would cause a redeployment event to happen. The resource-cache-based ClassLoader I talked about above could be used to cache compiled .java source. This would make the JDT compilation step much faster as it would only require a recompiling of modified .java files. * A blog Gavin mentioned to me talked about being able to cache an HTTP Session (or SFSB Session) between a redeploy. This enables Zero-turnaround even further as at runtime you can make a modification to your web application or EJB right in the middle of testing a web app. The way it would work is that the HTTP SEssion/SFSB session would be serialized and reloaded after a new classloader was created to pick up the class changes. I think this is a cool idea, but suffers from the same problems as Hot Swap: - I'm pretty sure that a schema change to a .class file will generate a different SerialVersionUUID for default serialization. So, we would need to use JBoss Serialization to ignore version id mismatches. - I don't know if a schema change (an additional field added) would break the serialized HTTP Session/SFSB Session on deserialization. - Because of both of these problems, I think just using the IDE to do non-schema code changes during and within a test run is good enough. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988437#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...