I’ve been reading the Core JSF book by Horst and Geary and trying to filter out the hype, specifically about tool support and multiple render kits, from what would actually be an improvement over the ancient version of Struts I use at work. I think JSF has promise and I am even pleased to see some of the improvements supposedly promised in the forthcoming 2.0 specification.

However, is this too little too late? I have not been so impressed with any of the web UI toolkits I’ve encountered that I have decided to give them a try for the day job. And the JSF 2.0 spec won’t drop until later in the year. Then there is the lag in someone actually implementing it. So even if it is worthwhile, how much more irrelevant will it be made by other platforms and toolkits?

For my current project, if I am going to switch toolkits, it has to be now. Having JSF 2.0 pending is actually a reason for not using JSF as we’ve got a built-in migration challenge if support for 1.2 starts to die off. It seems likely in the last few years, Java has inflicted more geek fatigue than earlier in my career, too. Or maybe it is just me.

I’ve tried to stay out of this debate. It is pretty non-sensical, as most religious debates are–vi vs. emacs, brace styles, etc. However, Robert Cooper makes some good points for consideration in defense of static typing. The first one, right off the bat, has nothing to do with safety but touches on one of my favorite programming principals: intentionality. His other points are well made and well substantiated.

I even tend to think that his points, if well received, might help improve dynamic languages, in this case specifically Ruby, without having to give up the advantages of dynamic typing. Unfortunately, when the original poster to whom Robert is responding thinks it is realistic or practical to just fire people for making mistakes that a bit more intelligence in the language design could easily help resolve–well, good reception might be asking for too much.

This idea is not necessarily new, though the addition of Google gives some weight to the argument. But I remember years ago spit balling about if we could just deliver an application server with a spread sheet front end, we’d be out of jobs as developers. There have been attempts to realize this before, I’m sure. Arguably, the hierarchical file systems of yore aren’t too from it. And yet the demand for developers continues.

A large proportion of applications are very basic and simply data driven. Which explains the popularity and power of RoR. But not all of them are. This may add a bit of fuel to the fire that is contracting the market for more skilled developers, but I doubt it will ever completely evaporate. There will always be applications whose business intelligence defies spreadsheet-ification and macro-ification.

I’m beginning to like Tim O’Brien over at OnJava. This piece on the operational issues and challenges supporting Java is the only article I’ve seen cover these issues. It certainly matches my experiences over the years building enterprise Java applications specifically for managed hosting environments. And there are some reasonable discussions and tactics worth consideration. In my current employment, we are definitely getting closer to the more blended roles he discusses.

Tim O’Brien, after his previous criticism of Struts 2, did some homework on Wicket, a framework he mentioned in the prior piece. I have not used Wicket, but this seems pretty objective and informed. I would still do a bake off between it and what I am used to, Struts 1, and other likely candidates, before given my own opinions. But this at least gives a good survey of what to expect when playing with Wicket. Sounds like wait and see may be helpful in the sense that it would at least give the documentation and APIs a chance to for some much needed simmering.

I’ve heard good things about Wicket so have to give this discussion of Struts 2 some consideration, as well as the original write up I mentioned. I think the fairest thing to do on the next project where the question is open is a bit of a bake off.

I haven’t actually played with the new version myself, yet, but this is the second write I’ve seen that has piqued my interest. I’d say I fall well within the description of those using the prior version, today, and will be looking for a project where I can try out the new version, see if it is worth migrating. The fact that, at least in theory, they’ve made a concerted effort to ease migration is encouraging. I reserve some skepticism, though, based on some of the questionable architectural designs (mainly what I consider to be an overuse of implementation inheritance, rather than programming to interfaces) and, to be perfectly honest, some pretty sketchy code I’ve read in their sources. In the interest of being fair, I’ll reserve judgement on version 2 until I’ve had a chance to use and read it.

With Java 6.0 barely a week out of the gate, it looks like Sun has started pushing early access releases of 7.0. Many are comparing this, feature and adoption wise to 5.0. I think closures are conceptually worthwhile, though there is much potential for a badly botched implementation. It may be time to dig up the JSR and check out the EA to see what’s what. I am already concerned about the property support’s implementation choices. My own open source project, Navel, builds directly on the JavaBeans API, so I am curious about anything that improves or simplifies it. However, if the arrow (-&gt operator really is the symbol they’ve chosen, I am not so keen. And I am really scratching my head over XML literals. In my view, Java programmers are typically the worst abusers of XML, in terms not only of using it inappropriately but going way overboard. For example, take a look at Struts and Spring.

I earn my living programming in Java. It is by no means the only language I am fluent in, though I currently find it the least annoying. The language itself anyway.

The JSR for Java 6 standard edition was finalized this week. I agree with those characterizing this is an incremental update. Even though I am ambivalent about the scripting language support, I expect that may very well drive very rapid adoption among certain circles. Or it may drive even more formerly supportive users away. Like the inclusion of JavaDB, this feels to me more like a concession to certain vocal minorities amongst the Java community.

I could be wrong.

Regardless, the only way I see better adoption of Java 6.0 than Java 5.0 is among the scripting fans. Given how many apparently have not even stepped up to 5.0 for compatibility issues, I don’t see how 6.0 being merely an incremental rev improves things.

Time will tell, of course.

It seems like those that are actually bothering to write about Java programming are framework crazy, in one of two distinct ways.

The first group, of which I have occasionally been a member, are all about building new tools, frameworks, and libraries, regardless of whether perfectly usable examples may already exist. To be fair, in some cases, this sort of competition is healthy. In other cases, though, its just wasteful and confusing.

The other group, though, which I have ranted about in the past on my podcast, want frameworks, libraries and tools to do every little last thing for them. By the content of this article, this O’Reilly blogger places himself firmly in the second camp.

Ordinarily, I’d just ignore a post like this, except that I, myself, have also been working with Apache’s XML-RPC library, version 3.0, this week.

I don’t have any legacy code, but have certainly gone through the pain involved in the kind of migration he is contemplating. Especially with the refactoring tool support currently available such effort is pretty limited. I shudder to imagine the size and/or complexity of his code base that would leave him reluctant to spend a half day just grinning and bearing it.

His complaint about having to run the library’s web server is just out and out wrong. They do provide one extension point that allows you to run in the web container of your choice. Personally, I’d prefer a bit more flexibility than extending their servlet, but it wasn’t that big a deal for my needs. I wrote my application specific code where needed, mostly for application authentication and called through the super reference into their automagic code.

Is it me, or have all the Spring and IoC advocates forgotten how to write glue code? He doesn’t like the built in support for just instantiating his handlers, without handing them some sort of configuration hook or execution context. Fine, but I solved that problem for my project in less than an hour, and I don’t even have any fancy-schmancy IoC container. My handler mapping implementation is all of ten lines of code. My application boot strap code grew by maybe another twenty lines, if that, to reflect over a list of service interfaces in my application and use a custom annotation I rolled my sleeves up and wrote to build all the context my handlers need.

As for his wish list, um, how about writing up a module for Spring himself that bridges the two systems and either contributing it to Spring or setting up a new project for it on one of the many free project sites? I wrote code that does just about everything he wants, except for integrating with Spring, in about a day. I totally disagree, the 3.0 library is pretty darn close to little more than a simple implementation of the specification. My only complaint, as mentioned, is the limited options for extension, but otherwise, I think it does the job nicely and frees me up to concentrate on concerns more specific to my application.

Bravo to Robert Cooper for being so frank. As a Java developer, admitting flaws with the technology, albeit in an area I personally don’t use, can often be hard. But the technology just won’t improve until those with a stake are willing to be this honest. Let’s call a spade, a spade.

This announcement seems oddly dated, though it is only around a week old. The latest release of the 1.5 JDK is .0_05, the article mentions the vulnerabilities applying to _03 and earlier. What I found more interesting when I came across this is the lack of an obvious announcement channel for JDK/JRE updates. The RSS link on the Core J2SE page doesn’t seem to work, or that would be the natural choice.

Looks like Java may be getting a heckuva speed boost next time out. And we can all pitch in to help.

Ha! I am reading both “Spring: A Developer’s Notebook” (Bruce A. Tate, Justin Gehtland) and “Jboss: A Developer’s Notebook” (Norman Richards, Sam, Jr. Griffith). Neither have explicitly mentioned it, but the sample code in the book and downloadable from the publisher both make it clear the authors are using Macs. When you see a path that starts /Users/, it is a pretty sure bet. If it was Windows, you’d see the drive letter, and Linux or BSD would typically use /home. Of course, both sets of authors could have create /Users on their Linux or BSD system, but that’s unlikely.

I saw this on the Apple Java-Dev mailing list. It would be easy to spew bile as a knee jerk reaction to this, but after consideration, I think it makes sense, for a variety of reasons.
Read the rest of this entry »