Automatically compile different languages in GWT

How to integrate internationalization and localization into a GWT application? Assuming you're familiar with GWT internationalization, you probably answered "just put a language resource file into the appropriate source path, make sure your UI references these keys appropriately, and that you're using the Constants and Messages interfaces for everything dynamic". Fine.

Let's say you've done all that. Your application is fully internationalized. Now you want to localize it to three different languages, and I don't care what those languages are. You don't want to compile for all of those languages because that becomes a lot of permutations very quickly.

My default GWT compile is six different permutations per language. Three languages are 18 permutations, or 24 if you compile a "default" permutation. It takes me 10 minutes on my old computer to do just a six permutation build. I don't want a 40 minute compile, especially if I know ahead of time that whoever uses this application is going to want French only.

I'm also using ant as my build tool.

So I decided to take advantage of a little bit of automation.

Step 1: Create a new module file for each language.
This module file inherits the old module file and customizes the language only. Filename is App_2.gwt.xml.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.4.0//EN" "http://google-web-toolkit.googlecode.com/svn/tags/2.4.0/distro-source/core/src/gwt-module.dtd">
<module rename-to='app'>
    <inherits name="com.app.App" />

    <!-- Language specific compilation -->
    <extend-property name="locale" values="fr_CA" />
    <set-property-fallback name="locale" value="fr_CA" />
   
</module>


Step 2: Modify the ant script to build using this language file.
<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler">
    <classpath>
        <path refid="project.class.path" />
    </classpath>
    <arg line="-war" />
    <arg value="war" />
    <arg value="com.app.App_2" />
</java>
I just changed the name of the GWT module that's being built, the rest of it's the same.

Step 3: Modify the ant script to copy the correct module over before the GWT compile even happens.

<copy todir="src/com/app" file="lang/App_2.gwt.xml" overwrite="true" />

All done. Now I can add new languages and all I need to maintain is a module file specifying which languages to include in a particular compilation. (And of course the language files themselves.)

Linux and Java report filesystem space differently

I ran into something interesting this last week. Linux's ext2 filesystem and Java have a different opinion of what free space means, to the tune of 5% difference.

Let's take a look at how each application defines free space. Linux provides a df command that can be used to check free space:

root@system:/$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 7834788 2111688 5325092 28% /dev/hda1

Filesystem: The name of the partition.
1k-blocks: The total size of the partition, in blocks of 1024 B.
Used : The number of blocks that are used.
Available: The number of blocks that are available for use.
Use %: Equal to [ Used / ( Available + Used ) ].
Mounted on: The logical name of the partition.

Note a couple things here:
First:
Used + Available != Total available.
2,111,688+5,325,092 = 7,436,780

Total - (Used + Available)
7,834,788 - 7,436,780 = 398,008 blocks unaccounted for.

A little bit of research turned up that by default, Linux reserves 5% of the available space (in this case, 400MB) to help ensure the system remains defragmented. The space is hidden under the root user's account, so that even if the filesystem fills up completely, the root user will still be able to login.

Java, on the other hand, can see this 5% hidden space, and it includes it in its free space calculations. Java would calculate the available space as (2111688 + 398008 blocks ) = 2,509,696 blocks free. Java thinks there is 32% free space when there is in reality only 28% usable space.

I used the File.getFreeSpace() and File.getTotalSpace() methods from the Java 6 API to get the disk free values.

If you run a Java application as the root user, the extra hidden space never gets used. df only reports used space of up to 100% used. If the hidden space had been used, the use % column would increase to a maximum of 105% when the entire disk was actually full.

You can use tune2fs to configure the amount of space the ext2 filesystem is allowed to reserve. The -r option will configure the number of reserved blocks.

The lesson learned? Java isn't quite as smart as it pretends to be, and "free" space does not necessarily mean both free and usable.

Hello World!

Hello World! Just created my first blog post and looking forward to adding more.

What is this blog about?

Obvious in Hindsight is about using the past to guide our future decisions. We all make mistakes and we all learn from them. The trick is to never make the mistake again. If you've ever heard the saying "Fool me once, shame on you; fool me twice, shame on me", this blog is the place to be.

Here I will be recording the mistakes I make, things I learned from those mistakes, and general thoughts on things that could be done better. The content will be geared toward software development in a variety of languages. I'm currently working with Java at work and at home, so that's what a lot of the early posts will be about. I'm certain that some other topics will definitely work their way into the discussion.