> > The more I've worked with the JBlanket code, the more I think it's > > nearing time to try a new architecture. Given the pain that's > > happened here, I certainly won't just spring it on anyone. > > Could be. We did try a few different approaches and found that byte code > modification > produced the fastest runs (way better than JDI or JVMPI). What kind of 'new > architecture' are you thinking of?
I'm thinking of investigating aspects. AspectWerkz has the possibility of runtime weaving, and the Eclipse group has just announced that AspectWerkz will be merged with AspectJ and the first release (production) will be this month. That means top support for aspects in tools and a good set of choices for either compile time weaving (AspectJ historical approach) and runtime weaving (AspectWerkz historical approach). The language used to choose join points seems more developed, and something like 'excludeIndividualMethods' would be much cleaner an easier to implement with that language than using the GUI to create an XML file -- and then referencing that file in two different Ant tasks. Another set of challenges I've had is adding the 'untestable' and 'excluded' categories. The references to the actual file name penetrates several layers of the current code, causing the Shotgun Surgery smell from Refactoring. I'd really like to make it easier to add different categories or subcategories, treat it somewhat similar to accounting in that those subtotals always roll up appropriately so that the number of methods always totals correctly accross the application. Another feature I found interesting from the article that I linked to in JBL-9 (http://hackydev.ics.hawaii.edu:8080/browse/JBL-9) is that you could look at a particular method and see all the unit tests that covered that method. This can help make sure you run the right subset of regressions on any changes to that method. It's possible to imagine an Eclipse plugin (going way out of my realm of actual knowledge and into dreamland) that could interact with either the Local History or the Team interface to find the methods that have changed and ensure that you have executed all of the covering test cases for those. You could put little error marker by those methods until they've been covered. Now you've got tool support for ensuring your code is properly covered, just like you know immediately if you've got a compile error. So my main frustrations are not performance, but features. Also, JCoverage has just got quite a shot of publicity and support lately. http://www.toolshed.com/blog/News/fork_this.html,v http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Test/Cobertura.rdoc > If it were me, the first thing I would do is profile JBlanket on a minimal > hackystat configuration (say, just hackyKernel). I wouldn't be surprised if > some > fairly small changes produced some fairly significant speedups, given that we > haven't > looked at performance for quite a while. That's definitely the way to go to improve the performance of the JBlanket release. No doubt. > Just out of curiosity (at this point), how come JBlanket won't > compile/run/work under JDK 1.5? The class file format is wrong. Check out JBL-7 and JBL-8. I'm pretty sure that there's an answer in either BCEL or the instructions JBlanket codes into the classes, but it currently (JBlanket 4.4) doesn't work for 1.5. Thanks, Tim
