There are often some issues that can waste several hours of your precious time: XML parser incompatibilities depending on your platform and application, i18n problems where several elements of your architecture aren’t configured well to serve correct encoded and localized content, class loader hierarchy nightmares, or even Jar Hell when different libraries you depend on require different versions of the same jar. Today, I’m going to concentrate on the first problem: XML parser issues.

I’ve just come across a clone of Groovy’s AntBuilder. It’s being built with JRuby and allows you to write your build scripts in JRuby by reusing Ant’s tasks.

That was a pleasure to see Ruby inspired by our concept of builders, and now, they also copy our own builders. I’d simply say that imitation is the best form of flattery. Kudos guys!

Last week took place the second GroovyOne meeting in Paris, gathering the main Groovy developers. The event went fairly well, despite some disagreement we need to iron out, we made quite a lot ofprogress on the Groovy front towards 1.0.

It’s been a real pleasure to meet together again, and I must say I really had a lot of fun there. But this meeting could not have been possible without the help and sponsoring of different actors. That’s why I particularly want to thank all those who helped me make this happen.

My friend Christopher just told me a very old bug in the JDK has eventually been fixed in Mustang!

UTF-8 encoding does not recognize initial BOM

Java does not recognize the optional BOM which can begin a UTF-8 stream. It treats the BOM as if it were the initial character of the stream.A Utf-8 stream can optionally beign with a byte order mark (see, for example http://www.unicode.org.unicode/faq/utf_bom.html). This is the character FEFF, which is represented as EF BB BF in utf-8. Java’s utf-8 encoding does not recognize this character as a BOM, though; the result of reading such a stream is a set of characters beginning with FEFF.

Read more...

C#’s fanatic Ted Neward is amazed at how cool C#’s anonymous generic methods are. He then gives an example of a little program that filters some entries according to a critiria, using some generic types and delegates. It’s about finding all persons from a set of persons whose last name is “Neward”. Sam Pullara even showed his own version of the same program in Java and explains that IntelliJ IDEAallowed him to type roughly 10% of the characters of the program thanks to the wonderful completion and code templating capabilities of that IDE.

We’ve got PIM applications, all sorts of PDAs, rich client GUIs or webapps on the internet or behind the corporate intranet’s firewalls. There’s the MDA approach to generate apps from datamodels, orapplication generation engines that build applications dynamically thanks to the interpretation of a metamodel. All these applications and interfaces to store all kind of data, personal or business related, generally sports a fixed and frozen structure. New developments are always needed for evolving your applications, and costly redeployments and interuption of services are often triggered.

Sometimes, there are some unlogical choices that are being made: JBoss chooses JSPWiki as a base for their Wiki portlet in JBoss Portal. They choose to fork and trim JSPWiki (rather than contributing to it) to be able to embed a Wiki engine in their portal as a portlet. Fine. But why not choosing XWiki? XWiki:

• is a member of the JBoss Open Source Federation,
• can already be integrated in JBoss Portal,
• and moreover can also be integrated in any portlet container (The proof is that the eXo Platform already embeds XWiki as a portlet).

That’s weird, isn’t it?

With the recent release of Google Talk, the fine chaps at Google entered the Instant Messenging market. The most clever step in that direction was their choice of protocol for their IM solution: XMPP. XMPP was popularized and standardized through the IETF by the Jabber software foundation with its famous open, secure, ad-free alternative to consumer IM services like AIM, ICQ, MSN, and Yahoo (quoted from their site).

A particular benefit of choosing an open platform is that it takes advantage of available client GUIs for instance, and moreover, it can leverage specific and standardized extensions of the XMPP protocol – called JEPs. The Jabber foundation developed an interesting set of complementary protocol extensions by allowing custom XML payloads to be developed. And there’s one JEP of interest for us today: JEP-0009. This JEP defines a method for transporting XML-RPC encoded requests and responses over Jabber/XMPP.

Okay, Google released its Google Talk client and its related services. This all sounds good and well, but alas, for us, poor corporate users, we have yet to figure out if it’ll ever work through our nasty proxies (with authentication) and firewalls (port 5222 should be opened?). I’ve tried tweaking the proxy settings myself, but it didn’t work. Unfortunately.

On paper, Google Talk certainly looks promising, taking into account the great services Google have come up with so far, but there’s really not much more than other competitors already provide. And in fact, we have yet to see the great features not available anywhere that we all expect from Google. We’ve become pretty demanding users… (and as we say in French “Qui aime bien châtie bien”).

At out last OSS-Get Together meeting in Paris last thursday, we’ve had the chance to have Thierry Templier, a Spring modules and a Jencks commiter, make an introductory presentation of the Spring Framework

On our wiki, he made available two powerpoints in French:

• a big 118-slides presentation on Spring,
• and a specific one on Spring and JCA.

That’s a lot of content to read for those of you speaking Molière’s tongue.

Moreover, on his blog, he’s got a very interesting entry explaining how to inject Groovy beans with Spring or how to access CICS transactions from Spring!