At 7:30, I attended Karsten Lentzsch’s JavaTM Foundation Classes (JFC/Swing) Technology Data-Binding Techniques. Kartsen knows Swing probably as well as anyone here, and he’s spent a lot of time thinking about Swing in all areas, from how to create cross-platform forms easily to better data-binding approaches. This session was focused on the latter. He started with an overview of the history leading to MVC, then he talked about the MVC variant Swing uses. He then discussed his proposal for a replacement for the MVC approach within Swing. In order to keep the Model and View in line without synchronization issues, he recommends a PropertyChangeAdapter that sits between the model and view, translating the PropertyChangeEvents to bean calls on the model. It seems an interesting approach, but I’ll need to play around with it a bit myself before I could recommend it further. Interestingly, Karsten explicitly warned us not to run out and apply his pattern. He emphasized that developers should study the pattern before use, and each team needs to have one expert on the pattern. Maybe I’ll be that expert, and maybe Scott will.
Next, I went to Sun’s 10,000 Classes, Five Databases, Three Operating Systems: Techniques for Multiplatform Enterprise JavaTM Technology Testing BOF with a couple teammates. The session what almost identical to what one of my teammates submitted (Scott Gelb is the one wearing the yofoshizzle shirt). I guess Sun gets priority. Our system is a bit smaller, but it’s more complex. We have 1500 classes, three databases, three operating systems, and three app servers. The presenters didn’t have the complexity of multiple app servers because they worked on the Sun Application Server team. I’m not sure I envy them for that or not.
Their approach is similar to ours in many (seemingly obvious) ways: keep the coding workspace in source control, make sure the workspace works on all platforms, have a logical irectory structure for your workspace, etc. There were a couple things we found curious, though. They packages their test suites (15-20 tests apiece) in ears for nightly testing. That means about 1500 ears generated nightly. We just don’t bother with packaging all that test overhead. Also, they have a set of core tests that take 15-20 minutes to run, and they require developers to run that set (the “Pulse Tests”) before every single commit. Well, we follow the philosophy of many small commits, so this would kill 2 or three hours of productivity for all our developers every day. We’d like that for blogging time, and it would probably help keep bugs out, but I’m not convinced they’re on the right side of the balancing act.
It was frustrating being at a session we essentially proposed and could have presented. Oh well