XhtmlValidator 0.2 is available as a source or binary distribution.

XhtmlValidator is a tiny Java library for programmatically validating XHTML. Version 0.2 fixes a bug with the list of errors produced by parsing a non valid XHTML document and adds JavaDoc to the release.

Thanks to Ahmed Hashim for spotting the bug.

So, Closures in Java, huh? Too little, too late, or just too late?

Before we get into arguments, I’d like to make myself clear to both camps…

Firstly, I like Ruby. At the moment, I like Ruby more than Java. I also like Lisp more than Ruby. I am also less competent in Ruby than I am in Java and I am even less up to speed with Lisp. So I am not trying to prove which one is better because I recognize I am not qualified enough to make this kind of judgment.

The web is full of praise and reasons as to why one should pick up Ruby, so I’m not going to preach Ruby here, but I have to admit I agree with most of the things the rEvangelists go on about. I’m probably one of them, come to think of it, although you won’t catch me admitting it in public….

There are a few things that make me skeptical about the whole Dynamic Language explosion.

At the moment, I can identify two reasons in relation to Ruby’s popularity.

The first one is obvious. Ruby on Rails. Ruby only properly appeared on the map post-Rails, something especially interesting, if we consider that Ruby has actually been around longer than Java. And Rails not only ignited interest in Ruby, but also revitalized the flames of languages like Python, SmallTalk, etc. This begs the following question: Is it Ruby that’s really this good, or is it actually Ruby on Rails?

The second reason has its roots in the first one. Rails came along and reminded developers that things don’t have to be that complicated. Given our inquisitive nature, us developers will always dive head first into new paths of knowledge and understanding. Undeniably, The Enterprise has stagnated Java to a level that many of us were just begging for something new to learn and explore. Rails hit the perfect combination of inventiveness and timing.

I am wondering, however, given Ruby’s less challenging (it is simpler) nature, is it going to stick around long enough, or is it going to be forgotten as Ruby related challenges become comprehended and conquered? I doubt this is going to be the case, mostly because of the sheer pleasure every developer I know who’s actually devoted some time into it experiences by developing in it.

One great achievement the Dynamic Language wave has managed is opening the eyes of Enterprise (ahem…) developers to Dynamic ways. Especially during the last 12 months, many Java coders, including myself, have attempted porting Ruby/RoR features to Java. And now, there’s a formal proposal for Closures and Local Functions in Java. The word function was OO blasphemy in Java circles not so long ago, by the way…

Then, of course, there’s Rife and its Continuations and Groovy and others, I’m sure you read about them all the time. I don’t mean to sound harsh, but I can’t come up with many examples of followers who tried to copy a leader ever becoming the leader themselves. If I want Ruby functionality, I might as well code in Ruby. I have tried and enjoy the aforementioned attempts very much, it’s just that I get the impression they’re trying to cover holes, not break new ground.

More importantly, at the moment, Closures and Continuations are the least of my worries when it comes to Java, which is the language I spend most of my time in, whether I like it or not.

I would definitely like to see them in Java 1.7, earlier would be even better. But before that I’d like more important issues to be addressed.

Issues like the growing trend towards every Class having a corresponding Interface. Like how most developers are completely ignoring Package level access. Seriously, IntelliJ IDEA by default puts public in front of every new Java Class. Why is that? All methods that are not private are public, when clearly, nobody outside their package should be accessing most of them. Why doesn’t anybody mention Component Oriented Design any more? Is it because it doesn’t do AJAX blink in one line of code?

The reason Java is losing momentum is because it is becoming (has become?) overly complicated. For no good reason, either.

I’d like to see focus shifted to the core characteristics of Java that made it such an interesting prospect at first, and these, in my opinion, boil down to good software design, powered by fundamental OO principles, not bells and whistles like Continuations, which, according to the Ruby FAQ, can be used to implement complex control structures, but are typically more useful as ways of confusing people.

I don’t know how many times I’ve embarrassed myself by writing an e-mail that went something like:

Dear Sirs, please find attached…

… and then completely forgot to actually attach the attachment. A couple of times I even went on to write a follow up email to apologize for forgetting to include the attachment and still left the attachment out of the e-mail again.

Thank God, then, for the guy(s) who created Attachment Scanner Plugin for Mail.app.

In several occasions, eXtreme Programming (XP) has received criticism for not being sufficiently scalable when applied by growing in size teams. Having worked on a few large - 20+ strong teams - projects, I can testify that delivery targets did not suffer one cent.

What, in my opinion, receives a slight hit, as a team’s size grows, is code quality. Now, that’s not the type of code quality that will noticeably, if at all, affect the end product the way the End User perceives it. It is a developer’s code quality I’m talking about. It’s about the perfect architecture and coding practices and elegant code, efficient solutions and patterns. The kind of code that makes you want to find a pen and put your signature on it, because it makes you feel proud.

I don’t think this is an XP-specific observation, it applies to all projects in which a large number of developers work on the same codebase, more so on XP, what with XP being people-centric and everything, you know the song.

So what do you do to guard the codebase from wandering off down the nasty path?

Unfortunately, 44.9995% of us developers fall on the bellow-average category. That’s not a statistic I came up with, by the way. I read it in a report which I fail to reference at the moment, but it looked serious enough… And it kind of makes sense. Even when someone comes up with The Absolute Paradigm, it is naive to assume every other member of the team will understand it, much less apply it.

As a team grows, I believe the development environment should adopt a somewhat more autarchic flavor.

Pair Programming and Code Reviews can be very helpful, but , in my experience, cannot sufficiently protect the codebase from slipping into Wild West territories.

For projects that need to operate in time critical situations, the - otherwise fine - restriction-free XP approach should be a little bit constrained. If there is not enough time or resources to bring everyone up-to-speed, up-to-speed should be enforced with Alarms that would ideally start screaming and shouting when somebody doesn’t do the right thing.

These are Alarms in the form of Unit, but mostly Functional Tests that will fail a build in case certain guidelines are not followed when coders check in their latest effort.

Most projects will make use of at least two full blown application frameworks these days. This involves tones of configuration and makes for an area where Build Alarms are particularly well suited for. A build should not have to suffer Logging switched to DEBUG mode, or configurations that have Hibernate spiting the SQL on the Standard Out should not be commited. A few neatly orchestrated Test Cases should be enough to leverage such situations.

CheckStyle can be useful, but it is rather restricted, although, with a bit of effort, can turn into a rather useful tool, especially if superficial rules are ignored and focus is given on more design focused concerns.

If you dread over-assuming non-type-safe Collections, a Build Alarm should go off when it encounters a public Interface’s method that’s not returning a strongly typed Array. If you’re not lucky enough to be coding in an environment that supports Generics, that is.

(I am deliberately leaving out the comparison of Java with other languages here, in order to avoid distracting attention from the theme of the conversation…)

I always try to remind myself and peers that TDD is not an option. TDD is something you just do. If a build breaks from day one when Test Coverage is not sufficient, the amount of confidence on the codebase acquired as the project matures is something that makes a whole world of difference.

TDD must become not second, but First Nature.

It’s like learning how to play guitar with a good instructor. They will insist on you holding those bar chords the right way early on. Fingers might hurt at first, but two weeks down the line you’re doing everything the right way. You learn faster and you play better. And bend a lot easier, too.

Such exercises might seem slightly painful, if not somewhat embarrassing at first, but everyone will end up much the wiser a few months, if not weeks into the project.

Wax on, wax off… Daniel Larusso didn’t win that tournament in one day, you know…

If you don’t know, Vienna is a freeware, open source RSS/Atom newsreader for the Mac OS X operating system.

I remember I tried out Vienna some while ago and found it rather nice, especially for a free piece of kit in early stages of development. At the time, I was still drinking the NetNewsWire Kool-Aid and didn’t bother making the switch.

That was until recently, when my bud Juanjo brought it back to my attention. We talked about it and both vowed to migrate because Vienna performs better, is free and, most importantly, is Open Source.

I am not going to go as far as claiming that Vienna is better than NetNewsWire, because it isn’t, but it’s not that far behind. It’s still a bit rough around the edges, but it has most of the features I require for an enjoyable, day-to-day weblog experience. A lot of work is being put into it and there’s a very interesting list of enhancements coming up in version 2.1.

In my mind, open sourcing your code is still a very noble thing to do and that’s the main reason I will always award extra points to Free (as in Open Source Free) apps when comparing them against commercial ones. After all, generating interest in them is an almost sure path to give the contributors incentive to make their application even better.

So, yeah, I did go to Vienna and, for now, I’m staying there. I suggest you do, too.

The lil’ Devil got a MacOS friendly cyber-facelift (or a really cool bike riding helmet), although the familiar imp is still present on the FreeBSD website. Maybe the FreeBSD people have been taking MacOSX hints lately, along with providing Apple with the foundation for the world’s most advanced operating system. Good…

You might have come across Steve Anglin’s article in defense of the Spring Framework seen many places around town recently. A lot of us should recall the time when Spring was first introduced as a lightweight aspirin to our JEE headaches. Few years down the line, how much simpler is the Java Enterprise application and what is the role Spring has played in remedying the complexity?

If we compare what was in EJB 2.0 times and today, yes, I believe things have improved. But let’s face it, it’s almost impossible to make things more unnecessarily complex than that. But looking outside the Java camp, I can’t help but be somewhat skeptical, to say the least, as to whether we’re on the right track at all.

On with discussing some of the misconceptions, because that is my intention here…

In regards to misconception number one about Spring not being lightweight: Spring’s primary goal is to enable lightweight development based on POJOs.. Ah, yes… Plain Ol’ Java Objects. Wired in XML which is not plain or Java at all. Complexity is not eliminated by pushing it out of the code into configuration files that are not native or natural to the programming language. It’s still there hidden behind another level of complexity. Spring is described as a comprehensive integration platform for other Java technologies. Most of those technologies are already pretty heavyweight. So the application does not become much simpler or lighter, more like glued together with declarative configurations in XML. And, no, Annotations do not make things much simpler, the way Xdoclet didn’t make things any better back in the day. If you disregarded the Xdoclet code, EJBs were not that far from being POJOs themselves. So I do hope Spring does not go down the Annotations path any time soon.

Quoting Steve again: For one thing, even simple applications typically require some enterprise services such as transactional database access. In my experience, even complex applications do not require transaction management the way Spring handles it. Also, what is it that is so difficult about transaction management that cannot be dealt with POJC (Plain Ol’ Java Code)? But let’s, for a moment, suppose transaction management is that difficult to deal with. Does the introduction of AOP make it less complex? No, because AOP is complex in its own right, so it’s just adding more complexity calories to the meal. You get your clean POJOs, yes, and then you proxy them, target them and declare their transactional behavior in XML. Again. And you’re not testing the transactional logic you define. At least not in an easy, natural manner.

One thing I like is programmatic transaction handling with Callbacks in Spring. That, in my opinion is clean and lightweight and a really nifty idea. It also takes about 10 lines of code to achieve without Spring Transaction Management…

Spring replaces Java Enterprise Edition. I wish… If this was the case, I probably wouldn’t be writing this right now.

For a large application, Spring’s XML can become a maintenance nightmare. Everyone knows this, everyone has thought how when the next project comes along we won’t fall into this trap and every time we fail. Spring can be forgiven for going XML the first time around, when everyone forgot to ask ‘why XML?’, but I think there are no excuses for the next version of Spring not supporting programmatic configuration.

If Spring aims at just being a cushion on the 10 Tone JEE hammer we bang our heads with, I’ll tell you what, it doesn’t hurt much less. I think the real problem lies in the fact that we need a framework, lightweight or not, to integrate other insanely complex frameworks to achieve tasks that are not as tough as they seem. So I don’t see that much injustice in complaining about something that doesn’t attack the problem with means to eliminate it instead of hiding it. It’s like miracle diet products. The bottom line is, if you don’t lay off those burgers, you won’t lose weight, no matter what the ad in the magazine says.

… or, what to do on holiday, besides eating, drinking and sleeping.