The installation documentation is incredibly extensive. Alas, I work in IT which means Murphy’s Law guarantees that the environment I’m given to work in will be unique, complex, and a million miles from a “Standard” setup. Consequently, I was dealing with reverse proxies, apache front-ends, https issues and more besides!

One issue that I did spend a while on was this one: http://jira.atlassian.com/browse/JRA-19051. Basically, JIRA has problems when installing on Tomcat 6 if you want to use a Context that is multi-level. So, something like “/servlets/JIRA” rather than “/JIRA”.

The fault is actually with Sitemesh that JIRA makes use of. Tomcat 6 uses a naming standard based on hashes as separators to specify a multi-level context. So, in the example above, the context XML and exploded WAR file is stored as “servlets#JIRA”. Unfortunately, this confuses Sitemesh who tries to drill into the expected Context directory structure and complains that directory “servlets” does not exist.

The issue linked to above is still unresolved and was raised in September 2009, so I suspect it’s probably a pretty low priority. I was able to work around it however by inserting the “<context>” stanza for JIRA in the main server.xml file rather than in a file of its own.

While this isn’t the preferred Tomcat way of doing things (any changes I make will require a Tomcat restart), doing the Context entry this way allows you to use the path attribute, where you specify the full Context path. Using a standalone Context file, you can’t use this attribute – it is inferred from the (special, hash-separated) file name.

I also used the docBase attribute to point to the exploded WAR file. I placed the exploded WAR file under the standard webapps directory, but nested to match the multi-level context path (so, something like …/webapps/servlets/jira, rather than the more Tomcat-6-normal /webapps/servlets#jira).

This was enough to get me up and running. I suspect it might also be possible to do something using an Apache proxy, whereby Tomcat thinks it is running single level contexts (/jira) and Apache proxies the requests to those single levels (so it converts requests for /servlet/jira to simply /jira). Unfortunately this wasn’t possible in the environment I was running in, so I haven’t pursued it any further.

Hopefully this run-down is helpful to anyone else who hits this issue!

I’m in the process of getting my head around Scala, but when installing the Scala Eclipse plugin into my standard Eclipse Europa setup, I got the message that Scala Plugin couldn’t be installed because it required “org.eclipse.pde.runtime”.

I found a few references on Google, suggesting a full installation of Eclipse (i.e not a standard install), or reverting to Eclipse 3.2.

Instead I had success by:

1. Go to search for new plugins with “Help” -> “Software Updates” -> “Find and Install”
2. Choose “Search for new features to install”
3. Select the “The Eclipse Project Updates” repository”
4. Expand the “Eclipse SDK Eclipse 3.3.1.1″ category, and select the “Eclipse Plugin Development Environment”

This plugin includes the required “org.eclipse.pde.runtime” package, so once installed you should be able to get the Scala plugin up and running.

Now all I need to do is to relearn functional programming from my Uni days…

There was a time when I was a Linux guy through-and-through. I moved back to Windows on the desktop when I got a new machine (although my servers stayed Linux…of course!). So, its fair to say I’ve been out of the scene for a while and didn’t really know where the state of the Linux art was at.

But thinking about it, 95% of my time on the laptop is spent surfing the web, doing email, and writing the odd document – Linux can do all those with ease. So, with nothing to lose, I used the new Vista functionality to shrink my C: drive, and went about installing Ubuntu Linux on the newly created space.

Wow!

So straightforward! I downloaded the ISO image, burnt a CD, and booted off it. 30 seconds or so later, I was looking at a Gnome desktop with a fairly full complement of available applications, and an “Install Ubuntu” icon. Great way to do things – you can try out the OS, see if your machine has any incompatible hardware, and if not, proceed with actually installing it to your hard drive.

Seeing no obvious problems, I hit install, and 20 minutes or so later I had a laptop which let you choose Vista or Linux at bootup, and proceeded from there.

The experience has been fantastic. From the get-go, my Dell Inspiron 6400 laptop could see all the surrounding wireless networks, handle sound (even the custom volume up/down buttons work a treat!) and had all the software installed to surf the web, read email, and write documents and spreadsheets.

Thats not to say it was all smooth sailing – getting the laptop to actually talk to my WPA-protected wireless LAN took a bit of work – the built in graphical client didn’t want to connect, but once I put the appropriate details in /etc/network/interfaces it was all good. That’s pretty much been the only hiccup!

I’ve installed a few more things now – Google Earth is up and running (way to go Google, for supporting Linux!), the latest JDK is in, and my one indispensable piece of software – the Eclipse IDE – is up and running (pictured). This is one of the joys of doing Java development – the Operating System I choose to use is almost irrelevant – I don’t necessarily need to be running a system identical to my clients.

Since I’ve installed Ubuntu, there has yet to be a single reason to boot into Windows. Ubuntu even lets me read my Vista NTFS-formatted partition, so I can still get to all my music and documents. I suspect that what I may end up doing is setting up the laptop as a pure Linux system, with a VMWare image if I do come across something which absolutely requires Windows.

Hmmmm. Let me think….. *scratches head* There must be something….

• I’ve continued to spend far too much time cursing at J2ME. When it comes to UIs, you either have full, low-level control where you draw every single pixel yourself, or you have almost no control where you populate a Form with Items and wonder what on earth it will look like on the various platforms. If only there was a happy medium… And yet, despite my complaints I can’t walk away – the lure of knowing your program can run on potentially so many devices is too much!

• I gave NetBeans another shot for my J2ME development with version 5.5, and decided all is forgiven. It feels way “snappier” than version 5, and I haven’t had it hang on me while using the Visual Designer part of the Mobility Pack (which is the killer feature for me). Good work guys!

• I’ve upgraded Wordpress around 50 times to cope with all the dot releases that have been coming out. I’m actually getting a bit excited about the big 2.1 version due out soon – I have a sister working overseas who has been a blogger in the past and toys with getting back into it – perhaps a snazzy new piece of software will be the impetus she needs!

• I finally decided to sit down and tick off something thats been on my To Do list for about 6 months now, and upgrade the search page at www.asman-it.com.au to use the new “inline” Google search results. And, like all things you put off for ages, it took around 10 minutes (although admittedly my page won’t win any prizes for aesthetic or robust web design!).

So, we’re back up to date. Perhaps my next post will be a little more on-time!

So, as all serious programmers know, you need fuel when your churning out top-quality code. Salty, calorie-laden fuel! Some swear by pizza. Others are into chips. BBQ Shapes are my programming snack of choice. I love it when you get one that has a lot of the “topping” – that salty red powder that gives ‘em their flavour!

But you can have too much of a good thing. Tonight, I reached into the box and pulled out a handful of Shapes to find, well….this:

(I promise, the biscuit is not a setup, thats how it came out of the box, and that spice “stuff” is packed on there like cement!)

Wow. Next step is to put it up on EBay, right? Surely there’s people who’d pay good money for that sort of “flavour explosion”!

In case you’re too lazy to click on the above link to the Wikipedia page, this is an example of Cellular Automata – a grid of “cells” that live and die according to simple rules. And interestingly, from very simple rules all kinds of ordered and complex behaviour emerges. Short summary? Its like a kind of fishtank for geeks!

CELLular (neat name, huh! You get it, right? CELLULAR automata. CELL phone. Huh? Huh? ) allows you to generate random grids, or to draw your own patterns, then set them in motion. And, as an added bonus, it does a nifty fade-in/fade-out effect as cells are born and die!

Here’s a picture of it “in action”:

You can download CELLular here, and it should hopefully run on most MIDP2.0 devices. Enjoy!

They have a few basic rules – no line over 80 bytes, etc, etc. And the examples take their input as a string of 81 digits, which represents the 9 rows of 9 digits, with “0″ being a blank square.

As I apparently have way too much time on my hands , I got up the motivation to convert one of these examples into Java. The results?

• The end program is around twice as many lines as the Perl original, and
• Yup – you can make Java programs as unreadable as anything else out there!

There may well be shorter possibilities out there – I didn’t put in a great deal of effort past converting the Perl original. But, for the record:

import java.util.*;public class S{static char[] A;static void R(){int i,j;for(i=
0;i<81;i++){if(A[i]!='0')continue;HashMap h=new HashMap();for(j=0;j<81;j++){h.
put(j/9==i/9||j%9==i%9||(j/27==i/27)&&((j%9/3)==(i%9/3))?""+A[j]:"0","1");}for(j
=1;j<=9;j++){if(h.get(""+j)==null){A[i]=(char)('0'+j);R();}}A[i]='0';return;}for
(i=0;i<81;i++){System.out.print(A[i]);}System.out.println();System.exit(0);}
public static void main(String[] a){A=a[0].toCharArray();R();}}

Assuming you have an appropriate classpath, you can run it with a line like:

java S 006070800000000000078601520030405010400000002090302060052103690000000000003020100

This code was converted from the excellent Perl example at:

http://www.ecclestoad.co.uk/blog/2005/06/02/sudoku_solver_in_three_lines_explained.html

Well, not really.

Just a cute phrase that occurred to me today when chatting to a colleague. We’d just spent 15 minutes discussing the desired behaviour of a system I was working on. Usual stuff – at first blush it seems straightforward, but plenty of edge cases, historical behaviour requirements, and other nastiness.

So we got it figured out, and its 11:45. Lunch booked at 12:00. No way am I even getting 10% of the code done in that time. But its just enough time to do the Javadoc.

So, 15 minutes later, my code has the 2 method signatures I need and around 40 lines of Javadoc describing the code’s behaviour, exceptions, and assertions. And after lunch, I was able to get straight into coding, all details of my discussion safely preserved.

And as an added bonus, when it comes time to rework it, I (or the next guy) will have some great doco to get started.

Not rocket science. Certainly not worthy of its own buzzword-esque title (although it does roll off the tongue ). And probably something everybody should be doing anyway as part of their actual methodology. But its a neat little anecdote worth telling!

After doing serious Java programming for at a least a few years, and having dabbled for a few years more (all the way back to the 1.0 days!), I’m pretty happy with my breadth of Java knowledge. Until a co-worker today mentioned using Collections.shuffle() to randomize a list.

“Pffffft”, says I, “Surely you jest”, says I. “No such thing.”

Well, there is. java.util.Collections (not Collection, note – theres an “s” on the end!). A nice, chunky class, full of juicy, static methods just waiting to save you from having to re-invent the wheel when it comes to operating on Collections. There’s the obvious stuff – shuffle() and sort() to randomize and sort, for instance. And small, but useful stuff – min() and max(), swap(). And some real useful stuff, like synchronizedList() (which returns a thread safe version of your list).

Many’s the time I’ve done my own “max()” routine. Each time, I trawled through the Collection interface looking for one and was mildly surprised it didn’t exist. And I never thought to look any further afield. I’m guessing that there may be one or two Java guys out there who are in the same boat (How many library classes are there now in Java?). Seeing as my co-worker doesn’t have his own blog…yet (come on H! Get your act together! ), I’m doing this posting for the other people like me!

Of course, I’ve always got the excuse for my ignorance that its a relatively recent addition. I mean, its only been around since Java 1.2….. *grin*

So, if the user passes invalid parameters, do you throw an exception? And, slightly more subtly, if your constructor encounters an exception during object setup, how does it handle this?

Interesting article and well worth the read.

But it struck a bit of a chord with me – I recently bought a Nokia N70 phone, and have been cruising the net looking at how you can code for these things. The N70 is a Symbian phone, and while it has J2ME support, the hardcore stuff seems to be done in C++. Now, C++ is an … interesting language, but is not really known for its in-built protection against memory leaks, and when you’re running a program on a device with limited memory, where your app may well run for the order of days or months this suddenly becomes a big deal.

OK, so you just code, really, really carefully.

Well, turns out that constructors are a special case in terms of memory leaks. Symbian doesn’t use standard C++ exceptions, but it does have an analagous concept called “leaving” grafted on. And not being a C++ guru, I couldn’t tell you what difference there is between normal C++ exceptions and the Symbian variety. In any case, the issue when writing Symbian programs appears to be this:

1. Constructor called
2. Constructor initialises an instance variable that points to some new object
3. On the next line, the constructor encounters an error and leaves

So, we now have allocated memory for some new object (step 2 above), but the object that owns it no longer exists – it crashed during construction. And because the object never fully formed, the destructor wasn’t run on it and so couldn’t free up the memory. Ladies and gentlemen, we have memory leak….

Turns out that Symbian programs have an accepted idiom on how to handle this stuff. Objects that can suffer this way have a static construction method (like the whole getInstance() idiom you see in Java). This static constructor creates the object using a constructor that only performs trivial operations that won’t crash, then once the object exists, calls an instance method on the new object that performs 2nd-phase construction. If things turn to jelly, there is at least a concrete object in existence, so the destructor will be called as normal.

Pretty neat. And pretty eye-opening as to the kind of issues you can be exposed to without garbage collection.

(Which is not to say that Java doesn’t have its own issues with memory leaks, but thats a whole other blog post… )