cwash into software » software development

OSGi-ggity-Giggity

Chris Wash — Wed, 15 Apr 2009 21:40:01 +0000

Update: A great article on OSGi popped up on Javalobby today. Check it out.

I haven’t yet written any thoughts about OSGi but it’s something that’s increasingly found its way on to my radar over the past year and a half or so. I’ve been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer’s talks on InfoQ about it). Needless to say it’s got me excited. Really excited – to the point where I’m catching myself geeking out uncontrollably like Quagmire from Family Guy. What’s got me all giggity? Let’s take a step back first.

With Java there has always been a focus on modularity, but it’s come up in different intermediate forms. Any typical Java developer can go on for hours about the importance for layering and properly isolating, decoupling and packaging components and subsystems. Java has the idea of a package, and the idea of JARs came about fairly early on in the process. But what became difficult was that often each layer had to have its own supporting infrastructure in place to be built independently, and someone needed to know how all of those JAR dependencies mapped out at build time and runtime. This was a necessary evil so that we could have individually deployable modules or subsystems. Once you got there, it was all worth it.

The problem was that while you may have been diligent and rigorous in your approach to applying how your projects were laid out and built, quite often the framework space solved this problem over and over again in many different ways. Going to upgrade a library was not an easy task, because you had to typically upgrade it across each of your layers, and what’s more, there was no consistent approach to manage transitive dependencies amongst the modules each library used. Library selection and dependency management was the work of a greybeard within your project and it took a while to change a library or upgrade. Not to mention a near certainty that you’d need to execute your entire suite of regression tests to make sure nothing broke.

After seeing many Java frameworks being cajoled into a Maven build in order to manage builds and transitive dependencies, there has been increased awareness on the part of the vendor (be it commercial or open source) space on modularity. But we’ve only focused on the problem of solving modularity from a build-centric view. In other words, “How can I package and manage these build artifacts in such a way that consumers can easily integrate them into their project in a consistent and automated way?” This was the pie-in-the-sky idea behind Maven as I see it, and they pretty much made it happen. You’d be hard pressed to find a framework today that doesn’t support it in some fashion.

But there’s a whole separate piece of modularity that takes place at runtime. In the context of my historical explanation of modularity within Java, you can look at OSGi’s ability to manage dependencies dynamically at runtime (via a header in your JAR MANIFEST file) as a “modularity win” and icing on the cake. But OSGi indeed goes farther than that. OSGi gives you the ability to install/uninstall, start and stop bundles dynamically (think Eclipse plugins) via its lifecycle, and that just plain gives me the “giggities.” To account for truly dynamic modularity OSGi also gives you requires and provides semantics (also declared via headers) akin to the requires and provides semantics you see in dynamic languages like Ruby and some Javascript packaging/dependency management frameworks. While this may seem like its strength is only in making a clear separation between APIs you use and export, its real strength is that this allows you to truly isolate your modules at runtime from trickery that can (and has) happened on a classloader level. “That couldn’t possibly work on an App server,” you say? I was skeptical, too, but not so fast…

If you’re the type that keeps up with the JCP space, you probably know there is a JSR “trinity” (equally as mysterious as its holy counterpart to the outside viewer) to provide a more robust modularization mechanism in varying degrees. That “quagmire” withstanding, OSGi has been mounting a considerable lead as the modularization system of choice in the JavaSE and EE/App server space. (It was already a formidable player in the embedded/mobile space, where it evolved from.) Nearly all major App server vendors have integrated the OSGi model into their core, which means they’ve probably cleaned up any classloader nastiness they’ve resorted to in the past. And now you’re seeing some of the leading frameworks like Spring and Web Beans/Seam 3 (and subsequently have signed up to publish themselves as OSGi bundles.) Not to mention the success that Eclipse has seen since refactoring itself to work off its OSGi implementation, Equinox.

If OSGi can continue to make inroads in the framework space, I think its prospects to the “in the trenches” Java developer are very exciting indeed. Expect me to babble on more about this in the future…

In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel

Chris Wash — Sun, 01 Feb 2009 01:16:05 +0000

Update: Robert Martin is scheduled to appear on the Feb 10 episode of the SO Podcast. Should be interesting to see where things go. Also, Jay Fields has weighed in on the topic.

Update #2: Listened to the new SO podcast and am working on a short followup post. I just met another local boy and kindred spirit in Justin Etheredge who has also had a few things to say about this whole debacle.

I wanted to add my two cents to this philosophical, in my view very important, but not very pragmatic debate. For the uninitiated, the argument begins with the Stackoverflow Podcast Episode #38 which is a discussion between Joel Spolsky and Jeff Atwood. They discussed, among many other topics, some of “UncleBob” Martin’s recent material found in his book Clean Code, (actually, Spolsky cited Martin’s appearance on Hanselminutes as the spark to his comments), which Martin responded to with a number of tweets and a blog post.

Jared Richardson introduced me to the idea of technical debt, (term was coined, like so many other terms, by Ward Cunningham) which I think is a pragmatic way to cut through the philosophical differences in this argument. But in the interest of carrying on the debate, and because it’s the weekend, I’ve decided to (perhaps) add some fuel to the fire. Please don’t read this at work.

The gist of the argument is about how much emphasis you should focus on robustness/code hygiene/maintainability in your code, even if it is unclear there is much business value in doing so. Essentially, if we consider impacts to budgets, deadlines, etc., and even in terms of its impact to your code (see Antipattern: “Yet Another Useless Layer”) — is it worth it? It’s very much a discussion of what software quality is and why is it important, which raises questions like:

Are robustness and business value mutually exclusive?
Does quality require rigor and conceptual cleanliness?
Is code hygiene a purely academic pursuit, or is there intrinsic value in it?

These are interesting questions. Atwood and Spolsky take what they feel is a more pragmatic position; Atwood explaining quality in terms of a Frank Zappa quote [paraphrasing] “Nobody gives a crap if we’re great musicians,” meaning that what matters is ultimately what is delivered to the customer. He explains further that “Quality is just another axis” — another set of competing concerns for your development time and interest. Spolsky’s comments constitute a self-professed rant that there is a thread of zealotry in the OO community around TDD. It reminded me a lot of what Cedric Beust has argued in reference to what Jim Coplien has debated with Martin himself. While Spolksy could be playing devil’s advocate, or could have been looking to start a “blog fight” (already popping up in comment threads) I think he could have gone about it in a more pragmatic way. While Beust does paint Martin as a zealot as well, at least his main point didn’t portray unit testing as just short of completely useless; rather, he is one of the creators of the popular TestNG framework:

“Tests first” or “tests last” is unimportant as long as there are tests.

I might be wrong, but I even remember reading a section of Clean Code in Borders last week and essentially reading Beust’s point in Martin’s book. It stuck out in my mind after watching his debate with Coplian. But I digress.

Before going further, I wanted to point out how much this debate reminds me of From pirate dwarves to ninja elves…, which I believe is a great way to classify personality types — especially those of people writing code. We know for sure that UncleBob falls into the Ninja-Elf quadrant. He thinks practicing TDD is a professional responsibilty and lays out his own definition for TDD in Clean Code. I think this is the very definition of a Ninja-Elf. My personal leanings are toward that quadrant as well. When you are innundated with Dijsktra, the ulitmate Ninja-Elf, in school, the following quote really sticks with you:

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself “Dijkstra would not have liked this”, well, that would be enough immortality for me.

But there are people whose opinions I respect with Dwarf-Pirate leanings, too. Obviously Atwood and Spolsky lean in this direction (though they may not fall directly into that quadrant). I’ve heard some others that I respect espouse the same opinion as Spolsky; Gavin King, for example, I’ve heard him say, “The types of bugs that I introduce usually aren’t caught by a unit test.” He wasn’t as over the top in his argument, he simply explained that he prefers integration tests. And I don’t think you’d hear any of the people mentioned in this post say that they never write any tests. For a great argument from the ultimate Pirate-Dwarf see Cal Henderson’s normalized data is for sissies (slide #27); it is pretty entertaining and compelling when scalability is of utmost concern.

I think Atwood’s argument ultimately came down to championing the idea of continuous production; that being able to respond to change or bugs found and having a quick no-brainer deployment process is the Zen-like state you’d like to get to. But the idea of getting there is that it comes out of some notion of continuous integration, which is predicated on the idea of testing. Henderson himself makes this very argument (I believe in this talk, but perhaps in another). You need to trust your team enough to get changes and fixes out to address problems quickly, and be smart about what you spend time on. Testing is great and if you can find people that can test their code well and be productive, that’s awesome. But Henderson’s point is those people are extremely hard to find and retain.

All this goes back to the old question, is producing code an artistic or engineering practice? (Interesting that Atwood supported his comment with a Frank Zappa quote about art.) Obviously you need a talented and cohesive team to be able to make it work either way. I think the answer is it has to be a little bit of both. You’ll need some measure of creativity, some degree of engineering aptitude, also strong analytical skills, and to succeed in a business environment, some acumen in decision making and managing (at the very least your own time).

The fact is, though, that we’ve come leaps and bounds in terms of being able to efficiently produce these tests, and balance their production and maintenance out with constraints, business expectations, budgets and deadlines. And it can fuel your creative side, too.

As for professional responsibilities, I definitely wouldn’t recommend trying to write code without at least some tests if you expect anyone else to have to maintain your code. If you’ve got a close knit team and an overwhelmingly urgent need to deliver untested code (and are of the Pirate-Dwarf persuasion) then go for it. But that being said, I’d say I agree with Martin and Jared Richardson that argue it’s a professional responsibility to not take on the technical debt of untested code. Of course, if tests mean you can get maintainability (and other -ilities) along the way then I think that you’re well on your way to a quality product.

One final way to look at this: would you say it’s better for your team to take the view that code is innocent until proven guilty, or guilty until proven innocent? In the interest of skepticism, considering the teams that most developers “in the trenches” have to work on, and how far we’ve come in making testing easier and more efficient, I’d need a very strong team to make the assumption that all they code they write is innocent. We all make mistakes. I believe this is also brought up in Clean Code.

Ultimately the message Atwood and Spolsky send in their Stackoverflow podcast is that unit testing and efforts to support it are not a silver bullet. Personal slights aside (“I don’t think these people write very much code.”) they have a point — and Martin agrees in his blog post. But I think it took them a long time to make that point which is certainly no great revelation. In the end, I did not feel they explained a whole lot about what the right approach to quality is, but communicated their distaste for an attempt (especially if accepted dogmatically) that aims to do so. I can relate to this, and agree you must treat what you read, hear and are taught with a healthy dose of skepticism. Martin’s ideas may seem dogmatic on the surface but I don’t think it’s fair to paint him in that light. If you really read what he writes, I think he realizes that he is a voice many people are listening to, and works hard to say what he thinks is the right. Martin defends a style of development that favors more rigor and discipline than many others feel is necessary, but in an industry that can be categorized by its lack of discipline, I can’t do much but respect him for that.

16 Apps That Lessen TEH SUCK of Web Development in XP

Chris Wash — Thu, 22 Jan 2009 00:43:48 +0000

Update: Sysinternals puts out some great developer friendly tools. They come in handy!
Update #2: I’ve made the switch to using Launchy over DOMercury.

Working on Windows XP is unavoidable at my job. While it’s not my favorite environment, I’ve found a decent baseline of software tools to augment the barebones OS that can get me to a place where it isn’t that bad. Note, I’m not including any tools for doing off-development related things, anything development related that is on the web or any cool plugins for any of these programs.

Here is what I need, in roughly the order I download them:

Firefox – I open IE, download Firefox with the purest intentions never to open IE again. Of course, my job gets in the way. I’ll save all the addons for this I install for a rainy day.
cygwin – first thing I do after making necessary LAF adjustments and installing Firefox. I don’t know how some people can survive without a robust command line… at the very least find, grep, sed, xargs. Also, if you don’t know what Ctrl+R does in Bash, check it out immediately.
Google Desktop – in lieu of not having Spotlight or anything similar, I set this to work early indexing
Eclipse – there is so much I use Eclipse for. Always one of my first downloads/installs even if it’s not needed immediately. Contains TCPMon, a Diff/Merge tool, great refactoring support, and about a million plugins to do many development tasks you’ll inevitably need to do (or want).
TCPMon – Whether you use Eclipse’s or some other, track this down and figure out how to use it. (HttpFox is great, but it can’t capture requests you make outside of the browser. Sorry, we’re not supposed to be talking about Firefox extensions, I know.)
Pidgin – best F/OS IM client out there for Windows (and other platforms). You can do some crazy stuff with Jabber, ladies and gents. But that’s another blog.
WinSCP – I don’t need to FTP or SCP files everyday, but when I do it’s usually easier to do it using WinSCP, and I can save my connection information incase I need to do something similar later.
PSPad – currently my favorite Windows-based “barebones++” text editor. In addition to the “coder-style” basics, a neat trick is that you can launch hyperlinks or filepaths by selecting and right-clicking.
vim – …Because none of these editors are perfect, though, I always keep ole’ vim on hand incase I get annoyed with PSPad. Honestly, I find myself in it just as frequently.
WinMerge – best F/OS Windows diff tool I know of – can compare directories which you can’t get the Eclipse merge tool to do.
SoapUI – general swiss army knife for anything related to web services. (Contains TCPMon, too.)
Squirrel – Ditch the Toad, go F/OS. Well, there is a free version of Toad but it can’t compete. As Jack White says, “Be like the squirrel.” Does whatever you want to a Database. Any database (well, almost). Written in Java, communicates using JDBC. Driver manager is a good way to get correct JDBC connection strings if you ever forget or can’t seem to get one right.
CommandBar – Found this mentioned in the Productive Programmer as a way to marry an Explorer and Cmd window. Comes in handy.
clcl – Another Productive Programmer recommendation for a simple multiple clipboard manager.
git – while I don’t always need this, I have been using it more lately because the version control software I have to comply with (eventually) on my current client sucks so mightily. I’m using git for day to day development and then I create a repo to interoperate with Harvest when I need to. (Be thankful you don’t have to use Harvest.)
DOMercury – Recent find that provides a Quicksilver-like launcher for Windows. It also includes an Alias manager. A priceless easter egg: ‘wtf’ launches IE. This sold me immediately. I’m not sure how well it keeps itself indexed, but I usually install it after everything else to keep it simple.

What am I leaving out? What kinds of things do you need to make your time in XP bearable?

On Software Quality

Chris Wash — Wed, 14 Jan 2009 02:27:04 +0000

Dwight D. Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is indispensable.” After reading Jason Yip’s No matter how many times you say it, we still don’t need a QA on the team, I started thinking about how similar this is to the correlation between (software) quality and exploring what software quality is. In the spirit of Jason’s article, thinking about how you “get quality right” will have more positive results for the sake of quality than searching out defects. So the question stands, how do you get quality right? I’m not sure there’s a cut and dry answer, but I have a feeling it’s in the details. I know it sounds anecdotal, but quality isn’t easy. It requires a lot of effort applied constantly. It requires reward and incentive, not punishment and fear. It’s caring about small things, and shifting how your team thinks, communicates and works together.

Jason wisely points out, “Everyone has a responsibility for quality.” But how are you ever to translate this to your team that plays the blame game, avoids at all real issues of quality, or blindly assumes that the “QA” (sic) will find all the product defects? How do you start this discussion, much less keep it going constantly?

Do you simply say, “Quality is your responsibility”? Or hang a sign on the wall to the same effect? I wouldn’t. The very idea of it undermines the ideal you’re trying to espouse: taking personal responsibility. It does nothing to encourage people to care about quality, outside of fear of losing your respect, maybe.

It’s leading by example. If someone finds a defect in my work, or takes issue with something I’m responsible for, I congratulate them with a “Good catch – thanks!” It may sound silly. It may even sound sissy. That’s natural. After all, we’re brought up, educated, cultivated with instincts to defend our own work. I wouldn’t be the least bit surprised to learn the average adult brain is predisposed to think this way due to the way its been “wired” through learning, and even, more philosophically, through our own sense of ego and intellectual self-worth. But think about psychologically what “good catch” does instead:

It acknowledges your teammate’s effort, and encourages that person to continue to put forth the same effort. Or more.
It encourages me to be more diligent in the future, even if I don’t agree 100%.
Most importantly, it tells my teammate that I care about quality, too.

Yet, all of this assumes people on your team desire to produce quality software. Somehow I had to tie this into Programming: Love It or Leave It, right? More rambling to come on this topic later.

24ways

Chris Wash — Mon, 01 Dec 2008 15:08:37 +0000

I can’t believe it’s already December! I came across 24ways last year and thought it was a neat concept: an ‘advent calendar for web geeks’ – take a look! They had a pretty good variety last year and I’m expecting some good things this year.

Must Haves/References For Modern Java EE Developers

Chris Wash — Sat, 29 Nov 2008 01:10:54 +0000

I’ve been doing a lot of reading lately and have been meaning to plug some of my favorite reads, and one of the things that I’ve been trying to read with an eye toward is for converting those that have been stuck on “behind-the-curve” projects to the new way of thinking and doing things. As such, and just in time for the weekend, I’ve compiled a list of my favorites with an eye to the “movers and shakers” that have driven innovation in the Enterprise Java world recently. Note that even though some of these links are specific to certain frameworks/technologies, there is a common thread throughout most of these that have a bigger focus on the best way to solve problems using Java 5/EE 5 constructs and concepts.

A book that should be on any Java developer’s shelf is Effective Java (2nd Edition). Make sure you get the second edition, for all of the Java 5 changes. This talk by Joshua should whet your appetite. (His talk on good API design is also very good.) You should also take a look at Bob Lee’s talk on Guice. Guice’s philosophy and focus on typesafety has spilled over into Web Beans (and newer versions of Seam) and its annotation based approach has heavily influenced newer Spring features. I especially like his points on type safety around the 11-minute mark. The walkthrough at the end of the talk from “old way” to “new way” is great for people who haven’t really gotten away from Factories, Delegates, and Service Locators yet.

The Guice video mentions that a common thread in modern Java frameworks is a focus on testability. Testing is a very important concept that nearly all new frameworks have embraced, but you still need know-how to be successful with testing. I’ve come across some great books recently in the automated (developer) testing arena. I’ve found the most thorough book on the topic out there is Lasse Koskela’s Test Driven. The ideas and topics discussed in the book are really language independent, and work equally well with other languages. To cut your teeth on TestNG, which the Seam documentation turned me onto, I recommend the TestNG developers’ book Next Generation Java Testing: TestNG and Advanced Concepts. Cedric Beust, also the author of EJBGen, and Hani Suleiman, author of the Bile Blog, produced a book that was a suprisingly good read. It’s packed with a lot of knowledge and some interesting takes on EE concepts. Newer versions of JUnit also include many of these features and concepts, so you’ll get the underpinnings of these concepts in this book. This video gives you a basis to TestNG’s approach.

As one of the growing number of developers who have an application in the Seam In Production page, there are a few Seam resources I have to share. Even if you don’t get into Seam, it should be on your radar because a lot of the core concepts around conversations have evolved into Web Beans, and are found other frameworks like Apache Orchestra and Spring WebFlow. Pete Muir did a Webcast that’s a great introduction to Seam 2.

Author of one of my favorite Seam blogs, Jacob Orshalick, has created a DZone RefCard for Seam 2.1 Core. It’s right off the presses, being published this week, but is a great quick-capsule review of what Seam can do for you, and nice to have on your desk if you’re writing Seam. If you need more in-depth descriptions of what’s on the RefCard, Jacob also coauthored the latest edition of the great Seam reference Seam Framework: Experience the Evolution of Java EE.
Dan Allen’s Seam in Action is another excellent resource. Of course, the awesome Seam Docs and Forums always come in handy. You should also RSS in.relation.to – the Hibernate/Seam developers’ group blog.

I know I’m leaving some great things out. What resources do you think someone who is used to J2EE should take a look at to get them “up to speed” with the state of the art?

How I Escape the “Reuse Trap”

Chris Wash — Sat, 02 Aug 2008 16:25:57 +0000

If you’ve checked out my blogroll, you’ll notice I have a link to Basil Vandegriend’s “Professional Software Development” blog. I like a lot of the articles he has written and to a large extent the subject matter I envision for this blog frequently crisscrosses with Basil’s.

While I was reading “The Reuse Trap In Software Design” I found myself thinking,”Me too! Me too!” like a giddy kid on the playground that’s found a new pal with a mutual interest in “pet snakes and/or tarantulas.” As with many of the problems Basil writes about in his blog, I experienced the same problem, investigated it and found the same root causes, and came to many of the same conclusions as those outlined. He describes the “reuse trap” as:

…[A] term I coined to describe the situation when one becomes stuck trying to design new functionality while simultaneously attempting to reuse existing code that needs some modifications.

He then goes on to describe why it’s a tough problem for n00bs and outlines a strategy he uses to get out of the trap–one that’s best described as a two-step process: copy-paste to reuse/refactoring to remove duplication. I encourage you to read his article if you’re not familiar with the terms, or how this strategy can solve the problem described above.

My preferred technique for mitigating the problems involved isn’t copy-paste reuse/refactoring; it’s stubbing the calls to the code-to-be-reused (C2BR) that needs modification. If I can fake out the behavior I need, it lets me focus on the nature of the dependency that exists between the two objects/components. When I go to modify the C2BR, my inputs and outputs (or other consequences that occur as a result of a call to the C2BR) translate directly into a test that I can use to drive the changes I make to that code. It also ensures that the coupling that exists between the objects is loose and legit.

The only thing to watch out for is that care must be taken to then remove the (small) duplication of the stubbed out inputs/outputs and actually wire the two pieces together when finished with the reused code. I usually do that by throwing a TODO:WIRE marker in when I stub something.

I’ve found this is the approach I take more often, though I do take the copy-paste reuse/refactoring route from time to time. This stub/rewire approach is a bit more advanced, but it’s how I envisioned solving the “reuse trap” when, as Basil puts it, “I became aware of it” and all that it entailed.

Do you ever come across this problem? How do you get out of this “trap” or avoid being caught up in it in the first place?

New Wave Logging

Chris Wash — Wed, 19 Mar 2008 19:34:39 +0000

Tired of messy logging logic cluttering your code with a bunch of if/else statements? Don’t let logging cramp your style! The approach Seam takes to logging makes your code pretty again (and other things). What does this mean for you? No more “code guards“!

A nice byproduct of the genius of Seam’s design is that many common problems can be solved by using EL as veritable swiss-army knife. We’ll look at this through a logging example specifically, though it’s just one of many different innovative ways of solving problems using Java5 features and EL as a general approach.

WTF is a code guard?

What goes without saying in most of the discussions regarding logging is that excessive logging can be the largest and most common performance bottleneck in code that meets its functional requirements. Thus, logging APIs introduce the idea of log levels, to ease the burden of excessive logging. Generally, log levels are a configuration setting on a per-environment basis. Development environments will typically log most dependent code at the info level, and cut that up to the debug level for custom code or when things go awry with a piece of dependent code. Testing environments typically log at info while production will often just log at the warn level.

While this is all well and good, we find that for a lot of the logging we do, we typically run across an ugly little flaw in this approach that’s produced an equally ugly hack as a work-around. Enter the code guard. From the log4j docs:

Code guards are typically used to guard code that only needs to execute in support of logging, that otherwise introduces undesirable runtime overhead in the general case (logging disabled). Examples are multiple parameters, or expressions (e.g. string + ” more”) for parameters. Use the guard methods of the form log.is() to verify that logging should be performed, before incurring the overhead of the logging method call. Yes, the logging methods will perform the same check, but only after resolving parameters.

What’s all this business about resolving parameters? Let’s look at an example:

// unguarded code
log.debug("FOO: " + foo + ", BAR: " + foo.getBar());

// guarded code
if (log.isDebugEnabled()) {
log.debug("FOO: " + foo + ", BAR: " + foo.getBar());
}

So, we need this cluttered if/else around only to ensure that our expressions (concats, usually) won’t get resolved unless we actually want them to. Why is there no other recourse? The answer isn’t surprising – it comes down to the way the API was designed. All log4j logging methods take a single argument — which made a lot of sense, I suppose when the powers that be first designed logging APIs. They soon realized that in order to use their API, one has to use an expression to resolve all parameters into a single argument prior to calling the method! This is why a code guard is needed.

Java5 introduces a feature that allows for varargs, and taking advantage of this can help us with our ugly little logging problem, e.g.

log.debug("FOO: #0, BAR: #1", foo, foo.getBar());

With this approach, our expressions won’t get resolved until after we’re in debug(), and we can let it do the dirty work inside the method. The first thing that our logging method does is check to see if its level is valid, otherwise it’ll fall out immediately. Because the concatenation happens inside the log method, we don’t need a code guard to protect us.

This is the approach that Seam takes to logging. Seam’s Log interface provides not only a solution that removes the need for code guards, it also allows you to use EL in your log messages (if you’re trying to dive into a Seam component…) – e.g.

log.debug("FOO: #{foo}, BAR: #{foo.bar}");

Much better. By and large, this is the way you do logging in Seam. Because binding occurs late, you never really run into the problem where you need to even think about using something like a “code guard.” Code what you’re supposed to; not noise! This is just one of many novel ways to use EL in Seam, and why it really deserves a look as a way to write better code, faster and as a far more productive platform for Java programmers (fed up with JavaSE/EE 1.4) than Rails/Grails.

See the Web Beans Manifesto for much more on this approach.

cwash into software » software development

OSGi-ggity-Giggity

More Related Content

In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel

More Related Content

16 Apps That Lessen TEH SUCK of Web Development in XP

More Related Content

On Software Quality

More Related Content

24ways

More Related Content

Must Haves/References For Modern Java EE Developers

More Related Content

How I Escape the “Reuse Trap”

More Related Content

New Wave Logging

WTF is a code guard?

More Related Content