Felipe Gaucho's Blog

July 2007 Archives

Java Unicorn - the W3C universal validator

I am visiting the web pages worlds these days - I confess it is not my metier, but this html trip is unveiling nice tools to minimize your the stress about validation and performance of web pages.

One of the hard tasks related to web performance is the large amount of details that can affect the usability round trip (request-server processing-response-browser rendering). During my preliminary tests, I asked my JUG communities about that, and they friendly suggested me a lot of server profilers, document validators, css and js inspectors, FireBug, YSlow, Tidy, Webalyzer, etc. The pandora box was opened and my screen seems a Christmas tree, full of lights and blinking alerts and reports :)

I just started thinking about a better way to run all the tests at once, and to take a coffee while the inspection bundle happens somewhere. Well, since I am in Christmas, my wishes seem to be considered - I found an under development W3C tool to test web pages in deep - it is called Unicorn.

The W3C Unicorn Project

From Unicorn Project Documentation:

• All these services are individually useful, but it is often cumbersome for developers of Web content to use them all sequentially and test as many aspects of Web quality as possible. The Unicorn Project aims to provide the big picture about the quality of a Web page, by gathering the results of all these tools into a single page.

I tried the tool and it seems the public preview has some problems, but since the code is available to download, I guess it is very promising - you can download and install in your web server, the Unicorn is a web application coded in Java. Meanwhile, I will continue navigating on the web design's world, trying to collect a bunch of good supporting tools and to generate a checklist about web projects quality. And, of course, I will keep on posting here the novelties about this hard task about web projects optimization.

The Gods Must Be Crazy - Java Edition

This blog entry is the summary of a long discussion I had with my friend Jason Brazile about Calendar and Date manipulation in Java. Jason is one of those agnostics against Java platform and he is also a high skilled developer and researcher, so our discussions often unveil interesting details about the Java language. This one made me be totally stoned.

How many concrete implementations of the java.util.Calendar are released in your JDK?

1. ONE: the Gregorian Calendar
2. TWO: the Gregorian Calendar and a new one from Japan
3. THREE: because there is secret Calendars somewhere
4. None of the above

Well, I have to admit I am quite surprise with the answer but, like a Java Puzzler, the most correct answer is: None of the above. If you ask this for a specific version of the JDK, perhaps I can guess how many calendars you have available - but the generic answer considers it is dependent of the JDK version, and probably also dependant on particular revisions of JDK nightly builds.

Skeptic? Just copy/paste and run the code below:

	public static void main(String[] args) {
		// JDK 1.5: This is the hidden Buddhist bug
		Calendar budish = Calendar.getInstance(new Locale("th", "TH"));
		System.out.println(budish.getClass());

		// JDK 1.6: This is the undocumented Imperial mistake
		Calendar japanese = Calendar.getInstance(new Locale("ja", "JP", "JP"));
		System.out.println(japanese.getClass());

		// Any JDK: nobody really knows about the type - suposedely Gregorian
		Calendar suposeGregorian = Calendar.getInstance();
		System.out.println(suposeGregorian.getClass());
	}

	class sun.util.BuddhistCalendar
	class java.util.JapaneseImperialCalendar
	class java.util.GregorianCalendar

In respect of my lovely technology I will avoid to transcript here my first thoughts about that, but I propose to the reader the following questions:

• What kind of Calendar is instantiated when you call Calendar.getInstance()?
  • Answer: I suppose it is GregorianCalendar, but if you are trying it in Thailand, who knows?
• PersonalJava API and debug packages are supposed to be available in the production versions of JDK?
  • Answer: to allow an API to run an unpredicted behaviour based on an undocumented library seems weird. The Japanese Imperial Calendar seems less complicated because its package follows the recommended naming convention and it is just not documented. But the Buddhist Calendar should be the preferred Calendar of Mr. Val Valentino
• If your system uses the Calendar.getInstance() method, is it safe? Even if some day it runs in a place containing a dangerous Locale? How easy is to find a bug if a developer is testing in a safe Locale and the production environment is in a dangerous one?
  • Answer: I have now answer for that ;) please help to enlight my mind on this topic.




The backslash of ResourceBundle

Posted by felipegaucho on July 16, 2007 at 01:48 AM | Permalink | Comments (6)



Few days ago I received a simple Java task: to take a comma-separated values (CSV) file and to create a Properties file for every column. The content of CSV file was delimited by semicolon; and the data was typed as the example below. Notice that first token of each line in the csv file represents a key and the other tokens should be split in different files - one for each language.

Original CSV file	Expected generated files
text.csv	text_en_US.properties	text_pt_BR.properties
key;pt_BR;en_US person.name;nome;name: person.birthday;aniversario:;birthday:; person.salary;salario=;salary=;	person.name=name: person.birthday=birthday: person.salary=salary=	person.name=nome person.birthday=aniversario: person.salary=salario=

To solve this problem, I decided to create an ANT task with the following algorithm:

1. Reading the csv file with a CSV Parser
2. Creating a java.util.Properties for each language defined in the first row.
3. For each row of csv contents (ignoring the header)
   • reading the first column as key
   • for the other columns
     • reading the column token as value
     • invoking setProperty(key, value) in the respective Properties file
4. Invoking the store(OutputStream out, String comments) in all Properties files.

Quite simple, and it worked since the very first time I run it. But when I checked the generated files, I got a surprise: the generated file included some unexpected backslashes before some characters. Checking the API documentation, I got other surprises about the store(..) method:

• The stream is written using the ISO 8859-1 character encoding.
  • SURPRISE: you cannot change the charset of the output :(
• For each entry the key string is written, then an ASCII =, then the associated element string. Each character of the key and element strings is examined to see whether it should be rendered as an escape sequence. The ASCII characters \, tab, form feed, newline, and carriage return are written as \\, \t, \f \n, and \r, respectively. Characters less than \u0020 and characters greater than \u007E are written as \uxxxx for the appropriate hexadecimal value xxxx. For the key, all space characters are written with a preceding \ character. For the element, leading space characters, but not embedded or trailing space characters, are written with a preceding \ character. The key and element characters #, !, =, and : are written with a preceding backslash to ensure that they are properly loaded.
  • SURPRISE: when you store a Properties object in a file, several transformations are being done in order to escape special characters.

The escape sequence rendering is well documented since Java 1.2, then I assume it was my fault not to know about that, but wait: I am developing software in Java for more than ten years now, and I really don't remember i18n files generated with backslashes - so I decided to ask about that in mailing lists. My suspicious was confirmed, almost nobody really knows about these minor tricks in internationalization Properties. Going deep in the code of Java I figured out the reason of this unconsciousness: the method getBundle(String baseName) of the class ResourceBundle supports special characters with or without the backslash, and since the most part of i18n files are created by hand, we never remember the minor details.

From my original example, we have the following output:

Original CSV file	Properties.store(...) generated files
text.csv	text_en_US.properties	text_pt_BR.properties
key;pt_BR;en_US person.name;nome:;name: person.birthday;aniversario:;birthday:; person.salary;salario=;salary=;	person.name=name\: person.birthday=birthday\: person.salary=salary\=	person.name=nome\: person.birthday=aniversario\: person.salary=salario\=

Interesting, a good reason to check the javadoc sometimes :)





Black Belt results at Jazoon'07

Posted by felipegaucho on July 02, 2007 at 11:45 AM | Permalink | Comments (11)



The prizes and and the competition format were very attractive: 5 questions about Java SE, with victory criteria based on velocity and precision. With that in mind I showed up in the competition arena trying to be as fast as possible - a strategy mistake I figured out few minutes later. The questions were really not so hard, but you know, all that minor details about immutable classes and types are the known enemies since my first Java certification. I really don't know what I missed exactly because after finishing my session I forgot to check the summary presented in the screen, we were all having a great moment with a lot of fun, so I shall remember next time to check better what is going on around my competition cockpit. I am not sure if spending more time would be helpful to my plans, but at least I had the honor to be the fastest competitor :) The competition was wonderful, Black Belt is definitely suggested to be present in all conferences because it helps people integration and it is a lot of fun. See you in the next arena.

Jazoon'07 Final Standings Place Name Country time correct answers 1th Júlio Faerman Brazil 2 min 04 seg 5 / 5 2th Perica Milosevic Serbia 2 min 11 seg 5 / 5 3th Dinko Srkoč Croatia 3 min 21 seg 5 / 5 4th Nikola Postolov Macedonia 7 min 08 seg 5 / 5 5th Felipe Gaúcho Brazil 1 min 15 seg 4 / 5





This work is licensed under a Creative Commons License.



Powered by
Movable Type 3.01D