Java - write once, test everywhere

Yes it has been a while since my last post. Been sidetracked with various other distractions.

Referring to my opening blog, just yesterday I received a phone call for the very same Dr Andrew Arch of Melbourne. Last year I received a confidential internal email from where I was working mistakenly sent to me, rather than my namesake, which I had to reply that they had the wrong Andrew. Our worlds are colliding - lol.

I have a simple web application to make life simpler for myself and my clients who I'm currently contracting for on an ad-hoc basis that acts as a simple http file transfer portal. My clients cannot get out from behind their corporate firewall using ftp, as their ftp ports are blocked, so I have a simple website where we can upload and download files from, simply by using our browsers using standard http, allowing the exchange of files too big for email and avoiding having to burn CD's and courier them across to each other. No database is involved, the files are simply saved into a dedicated folder on the Linux box and retrieved on request. But even if they could technically ftp to my Linux server, these clients are not that tech savvy to put them (read me) through the angst of using an ftp client. Better to use technologies they are familiar with than introduce new ones if you want easy adoption and little hand holding. There are exceptions, but its a good heuristic. Even then keeping things as simple as possible and as much in their experience space as I can, I'm now being asked for a tutorial on how to login, select the file and open/save the selection from a list of hyperlinks! You can never underestimate the lack of technical knowledge/expertise/comfort in the general community.

I develop on Windows XP and run my website on a Ubuntu 8.4 linux server distro. Both my Windows desktop and the Ubuntu server are running Java 6. I have tested with Firefox, Opera, Safari, Lynx and IE 7.0 from both my Windows XP desktop and my Ubuntu Linux laptop. My clients use a mixture of Windows 2000 and Windows XP and run IE 6.0, constrained by their corporate SOE. This exposed two variations that I hadn't catered for that caused me some minor issues.

While my combination of platforms and browsers all passed with no problem, when the clients attempted to upload files, the file name was saved as the full UNC path. So I had to cater for that scenario, which was a pain. I couldn't adequately test for it in my environment, as I couldn't reproduce the behaviour, and I wasn't about to rebuild my machines to match their environment, especially as this web site is more of a gesture of good will on my part than a full fledged production solution warranting an exponential combinatorial explosion of test scenarios. Still, it was a scenario that I should have in all rights anticipated and allowed for, as it was in hindsight predictable. But coding a fix was really guess work without a way of reproducing the issue. It also raises the question of just how much testing is appropriate given the huge variations of browsers and OS's that a web site has to deal with? Particularly if you are a small startup with limited resources vs what such trivial issues do for your reputation.

The other one was a classic cross platform issue. On my Windows development platform, a file with multiple consecutive spaces in the file name gets saved to the dedicated file directory. To view what files are in this directory, a call to a backing bean returns a List of Files and a call to Java's File.getName() method displays the file name to the web browser, as the JSP iterates through all of the File objects in the List representing that dedicated file directory. Works on Windows with no problems, with the only idiosyncrasy being that the HTML collapses the multiple consecutive spaces down to a single space in the browser view, but the underlying reference to the file name remains unmodified. Now potentially, I could address this browser behaviour as well, encapsulating the file name in a <pre> tag to preserve the white space or replace all of the spaces with non breaking spaces, that is if it really bothered me that much.

On Linux the behaviour is a little different. The file on upload is saved correctly using the Java File object and an Output Stream, retaining the multiple spaces in the file name. However, the call to the Java File getName() method returns a file name that has had the multiple spaces collapsed, just like a browser does to consecutive white space characters. So now, when you request the file to download, it doesn't exist, because the file in the directory has multiple consecutive spaces in its name, and your requesting a file with only a single space in any one place within its name. So I am reluctantly resorting to collapsing any consecutive spaces from the file name before saving to disk, as I have no ability to influence the behaviour of the Java File object on Linux, as far as I'm aware.

A search on the Internet came up with nothing related, other than that it is not advisable to use spaces more so that just about any other character in a Linux file path, and even in Windows, I still run into various problems attempting to run various Java applications that have spaces in the path. The amusing thing is when the Java application installs itself into the Program Files directory, which obviously has a space in it, yet it cannot run because of that space. Eclipse and JBoss are two such examples. For some things, they run fine in the Program Files directory, for other things, they just crash and burn. So if it causes them so much trouble, why do they have their windows installers install into the Program Files directory? Madness I say.

So now saving files to my little file transfer portal runs the risk of modifying the file name, which is not a good thing. But alas, without having found an alternative solution, I have to tell my clients to use my little web file portal with caution, as I cannot guarantee the integrity of their file names. You have to love universal environments. If only they could all learn to live with a space or two.