Scripting is definitely in fashion these days on the Java Virtual Machine. The JavaOne 2006 session catalog is online, and by browsing it, you’ll notice there are several sessions and BOFs dedicated to scripting. By simply searching for the word “scripting” in the content catalog viewer, you’ll count no less than 13 sessions speaking about scripting.

This will be my first time at JavaOne. And a big first time since I’ll be presenting a session! Along with Tugdual Grall from Oracle, we’ll be presenting TS-1246 entitled “Simplify Enterprise Development With Scripting” in the “Core Platform, JAVA SE” track. The abstract of the session is:

As a gift for mentoring students for the Google summer of code 2005 around some project ideas for Groovy, I just received a nice tshirt roughly on time for Christmas!

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.