I’ve spent the last few days doing a bit of a snooping around our translation tools workspace, trying to see what it would take to start to make some sense of our package structure. If you’re new to Sun, or haven’t heard, we like to perform re-orgs pretty frequently – change is good, right !?

Well, as a result of our team having different names depending on the weather (pretty much), coming up with a coherent java package naming strategy for our translation tools over the years has been quite amusing. We started out writing new code under com.sun.tmc... (the Translation Management Center) but then after a re-org continued writing any new classes as com.sun.tlis... (Translation and Language Information Services) and finally com.sun.transtech or com.sun.tt (Translation Tools, depending on who you ask) — quite a mess ! Running a quick command over the workspace, find . -name \*.java -exec grep -h '^package ' {} + | sort -u | wc -l, showed that we have a fairly whopping 225 (count them!) packages, all nicely scattered amongst those top-level names.

To try and make sense of this madness, I’ve been messing about for the last while in an xemacs window, putting together a simple script that can repackage the whole lot : it’s mostly bourne-shell, with bits of perl here and there, but seems to work okay (wow, my perl is rusty – I do everything in java these days, and it shows!). The script changes the name of the package, re-houses the file in the correct directory hierarchy, and then goes to work doing the string replacements for any imports or fully classified class names that are defined elsewhere in the source. So far so good : now we just need to get them to agree on the final name of the project we’re going to be open sourcing the tools as, and we’ll be able to turn the crank and have this script create order where once there was complete and utter chaos. (well, perhaps not quite “order” – maybe “controlled disorder” would be a better way of describing it. Things definitely look better now though, so it’s good enough)

Just to point out as well, that Netbeans has had support for refactoring for quite some time, I just wanted to be able to bulk-rename across a large code-base (repeatedly, so that we
can cope with the inevitable renaming of the project before we ship) For small bits of refactoring, Netbeans is definitely the way to go.