So once again, another Java User Group Saxony meeting is over: Yesterday, on July 16th, our seventh evening of lectures and communication took place, once agan located in an auditorium of TU Dresden Faculty Of Computer Science, and roughly 30 people (less than in earlier meetings, but still a good number considering the time of year and the overally warm weather…) came to listen to two pretty high-quality lectures announced to be focused on the Groovy programming language and its use in real-world applications. In the end, it turned out to be a little different than that but very interesting nevertheless…
After some fight to get the high-tech environment (well, mostly the beamer again…) in the auditorium to work as expected, Christian Wurbs of Dresden based software development company itemic started over giving an impressive presentation on what was supposed to be focused on using Groovy in extending an existing application but ended out to be way more: Trying to add not just scripting extensibility to an existing application but also to provide external customers with a reasonable tooling to build, store, debug and run scripting projects within this environment, the presentation included a whole set of technologies involved in this project, along with “lessons learned” statements which usually makes those introductions most useful. After all, Groovy was just a small and more or less unspectacular part of this presentation, which, asides this, focused on…
- …storing script sources, binaries and other artifacts in a JSR-170 compliant Java Content Repository implemented on top of Apache Jackrabbit,
- … utilizing aspect-oriented programming approaches , more specifically AspectJ, to seamlessly extend an application with scripting functionality without having to touch the main codebase at all,
- … and, finally, making use of the JVM Tooling Interface (JVMTI) and the Java Platform Debugger Architecture (JPDA) to build a custom debugger helping external developers finding and resolving errors in any self-built scripting code.
As I spent the last couple of months with this technology I can’t comment on the JCR presentation in an unbiased way, but about the other technologies the explanations and demonstrations were “to-the-point”, got one interested and surely provided enough insight (given the limited amount of time) to continue playing around with each of these technologies. Overally, an interesting and inspiring lecture.
The second presentation to follow a short break was done by Michel Loehr of Saxonia Systems, who provided an outline on how to make use of domain-specific languages in general and, then, of domain-specific languages based on Groovy to get the process of testing software user interfaces “automated at high speed”. Most notably here, indeed, to me was the significant ease of readability in testing code written in Groovy compared to testing code written in Java using a similar platform. Adding to his presentations, he showed a short live example of how to bidirectionally integrate Groovy code with Java code, which also is a pretty good thing if wanting to make serious use of another language on top of the JVM platform. So overally another inspiring presentation, which left me with two things noteworthy:
First off, Michel started his presentation quoting a rather old NIST report investigating the need to do thorough software testing, and I find this figures to be pretty impressive:
Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a newly released study commissioned by the Department of Commerce’s National Institute of Standards and Technology (NIST). At the national level, over half of the costs are borne by software users and the remainder by software developers/vendors.
The study also found that, although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects.
And, the second insight of the evening was getting to know Groovys “Elvis Operator” which, asides being really helpful at times, in terms of its naming surely once again demonstrates that software developers tend to adhere to a special kind of humor. :) Concluding however, it was a very interesting meeting worth visiting, once again, I’d like to thank the lecturers for spending time on that, and I’m looking forward to our next meeting to take place on September 10, 2009, when Adam Bien will be our guest talking about “Extreme Lightweight Architectures (XLAs :) ) using Java EE 6 and EJB 3.1”. See you then.