Agylen

I’m blogging this from the exhibition floor of the Java Conference ‘05 in Milan, where we have a presence. You’d expect that technical conferences like this one have free WiFi connectivity, but yesterday the only access point that I could detect led to a gateway page for a for-pay service.

Today I discovered an open access point instead. I don’t know if it is open on purpose but it doesn’t seem to be provided by the organization. Anyway, HTTP works, ssh works and Skype works, but IMAP, POP and AIM do not go through. Strange.

I briefly stuck my head into the room where Craig McClanahan was extolling once more the virtues of JSF but after five minutes I decided I wasn’t interested. In the afternoon I plan to attend the session by my namesake Ugo Landini on patterns, which promises to be entertaining. I wonder whether there’s going to be WiFi in that room.

I haven’t been doing “rich client” applications for a long time and did just a little Swing development at the times of Java 1.2, preferring to concentrate myself on web applications instead. With all the new developments around the concept of “Rich Internet Applications”, Ajax and the like, I don’t think I’ll be doing GUI development in Java at least for the foreseeable future.

However, I read with the utmost interest the comparison between Swing and SWT that was published today on Hacknot. You never know when you you might find yourself in the kind of situation described in the article: being forced by the management to adopt a technically inferior solution for no apparent reason.

The article is, as usual for Hacknot pieces, quite long and well documented. I suggest you read it all by yourself, but if you’re lazy, I’ll quote the main conclusions:

My prediction is that SWT will continue to limp along in support of Eclipse; neophytes will continue to discover it and sing its praises until such times as they’ve used it enough to realize its limitations; the uninformed will continue to attach a significance to platform fidelity that their user base does not; and marketers will continue to talk of SWT ‘taking over’ from Swing - as they have for the last three years - despite the lack of evidence that such a takeover is actually occurring. I expect the enormous maintenance burden incurred by SWT’s multiple code bases to become the limiting factor in its ongoing development, and cross-platform stability and consistency to remain ever elusive as SWT rushes to keep apace of the progress and initiatives amongst the native widget sets of different platforms. Any claims to better performance will finally be abandoned in the face of increasing capabilities of the average PC, leaving SWT an anachronism without a raison d’etre.

I don’t know if it’s just us, but we seem to periodically run into the same troubles concerning character sets in Java web apps. This time I got bitten once again by the bug that causes international characters entered into an HTML form field to come out as an unintelligible string of random symbols when displayed on another page.

Some time ago, I came to the conclusion that if we used UTF-8 everywhere, we’d have had less problems. And, indeed, by encoding all files in UTF-8, setting container and form encoding to UTF-8 in web.xml, ensuring all pipelines are serving UTF-8 streams, putting relevant <meta> tags in the HTML output, specifying UTF-8 as the charset in JDBC connection properties and having an UTF-8 encoded database, when a problem comes up it is a safe bet that someone, somewhere forgot one of these precautions and fixing it is usually just a matter of finding where.

Until today, at least. Today I spent a few hours fighting with this kind of bug and painstakingly reviewing everything in order to make sure that UTF-8 was specified everywhere, to no avail. At last, I gave up and set page encoding to ISO-8859-1 and everything is now hunky dory again.

Sometimes I wish all the world stopped using national character sets and everything was encoded as 7-bit ASCII once again. 127 characters should be enough!

Dear Web,

I have the following problem: I need to adapt some code that reads an image from a file using JAI to read it from an array of bytes having exactly the same content as the file. The code for reading from a file is quite simple:

RenderedOp img = JAI.create("fileload", "filename.jpg");

My problem is that I don’t have the JPEG file on disk, but it’s in memory inside a byte[] and I guess that I should do something along the lines of:

RenderedOp img = JAI.create("WHOKNOWS", data);

Or:

RenderedOp img = JAI.create("WHOKNOWS", new ByteArrayInputStream(data));

I couldn’t find anything googling around, the JAI documentation is a mess and the FAQ is of no help.

Please help! What operation name should I use instead of “WHOKNOWS”, assuming what I’m trying to do is even possible?

Please note that the byte array does not contain a raster, but a JPEG-encoded image.

Hibernate 3.0 released!: “Hibernate 3.0 is the world's most sophisticated ORXM (Object/Relational/XML Mapping) solution. Hibernate3 makes it easier than ever before for Java applications to interact with persistent data, allowing a single definition of the transformation between various in-memory representations of the entity data and the relational schema, even in the case of very complex legacy schemas and schemas for historical data or data with visibility rules. Hibernate3 also provides the most comprehensive object/relational query functionality, with three full-featured query facilities: Hibernate Query Language, the newly enhanced Hibernate Criteria Query API, and enhanced support for queries expressed in the native SQL dialect of the database.”

If you've been following this blog, you certainly know that I'm a big Hibernate fan. So I'm very excited about this release and can't wait to start using Hibernate 3. Before I start using it in production, however, I will have to wait for a Spring release with Hibernate 3 support, but I hear that's not so far away, fortunately.