It is commonly-believed that grabbing the user.dir or user.home system properties in Java is good enough, when it comes to making use of a user’s documents folder. Well, they get you part of the way there (although they don’t necessarily mean what you think they mean), but if you want a more resilient bit o’code, this may float your boat (note that this makes use of the Swing API):

return javax.swing.filechooser.FileSystemView
  .getFileSystemView().getDefaultDirectory().getAbsolutePath();

Less useful on OS X (just returns a reference to the user’s home directory so you may as well just carry on with user.home) but good for Windows, where it returns a reference to the user’s “My Documents” folder—I think it’s internationalisation-friendly to boot.

Chapter 3 - A Monstrous Forest.

Chapter 3 was a huge challenge for me as I wanted the first impression of the Wormworld to be a lasting one. This chapter is the longest chapter so far and it is full of elaborate full scale backgrounds. Including prelim, concept art and layout, I worked over 400 hours on Chapter 3. I think that it shows and I hope that everyone will enjoy the ride.

And then we have something else, which I must confess I hadn’t seen coming (I’ve just been too “heads-down” lately to know what’s going on in the Java world):

Oracle Releases Java SE 7 Update 4 and JavaFX 2.1

First Java Development Kit and JavaFX Software Development Kit for Mac OS X Available From Oracle

(My emphasis). Crikey! Read more (and get the JDK) from Oracle.

String tmp = someDoc.getItemValueString("someDateField");
String arrTmp[] = tmp.split("/");
int year = Integer.parseInt(arrTmp[2]);

That which is seen in one’s IDE cannot be unseen. Don’t do this at home kids.

target name = "clean"
target name = "build"
target name = "test"
target name = "deploy"

Now, for a clean target, I used to do something like this:

<target name="clean">
  <delete dir="src" />
</target>

Simple and to the point eh: get Ant to delete your source directory, ready for the “build” target to, well, re-build it. Super, smashing, great. But if you use source control (and of course, you do) you may run into a whole world of trouble with this approach. For example, one of my clients uses Subversion, and I started to see these sorts of errors when attempting to commit the changes resulting from the build:

Working copy not locked; this is probably a bug, please report
svn: Directory '/Users/SeymourButtz/Workspaces/Eclipse/Naffproject/src/.svn'
containing working copy admin area is missing

Lawks! “Fear not” I said to myself, and popped off to the Ant manual “Delete” page. Once there, I discovered that I simply needed to get down with the kids, and update my Ant skillz. Don’t use the square old delete dir=… directive! Use this badger instead:

<target name="clean">
  <delete includeemptydirs="true">
    <fileset dir="src" defaultexcludes="true" />
  </delete>
</target>

Slightly more verbose, but also a lot cleaner (pardon the pun): it wipes out your src directory as before, but having that defaultexcludes flag means the operation preserves any “required” sub-folders, which typically comprise such hidden gems as .svn and .cvs

Hip hip hooray!

(By the way, more on the Subversion error can be found in the FAQ).

The hard reality of the corporate coding way of life is that various people always want to know what you’re doing, what you’ve fixed, what changes are in what release, and so on and so forth. When it comes to Domino development, this is where a tool like Teamstudio’s CIAO! comes in to play. If you’re diligent about providing check-out comments, and you tag up a version within CIAO! every time you do a build for your deployment / admin. team, you already have the wherewithal to produce complete change logs, with next to no effort. How? Simply make use of this menu option:

Smashing stuff; can’t recommend CIAO! highly enough, even just for this sort of thing, never mind all the versioning / team development splendour.

But what about non-NSF code? What about all the stuff that you may ram into different version control systems? Well, I’m living in Eclipse at the moment, and as the project utilises the skills of a whole panoply of developers, CVS is a must for us. Every time we do a significant release of a component (our project encompasses two different—but related—modules in CVS), we have to provide some form of change log. And casting your mind back to the exact change you made to fix some bug, three weeks previous is tricky to say the least. What you need is some kind of tool for producing your change logs.

I have found such a thing. Moreover, it is really simple to use, is open-source, and it’s free. Allow me to introduce you to CVS Log Change Builder. CVS Log Change Builder is a simple soul in that it just comprises a single Perl script.

That’s it, no executables or other bits of nonsense, just a beautifully simple tool (assuming you have a CVS client on your path).

OK, how do you use it? Well, first up you need to edit it to point at your CVS server like so:

my $CvsRoot=':pserver:USERNAME@CVS_SERVER_NAME:/CVS';

Once that’s done, copy the Perl script to the check-out root of the module you wish to report upon, and run the script. Here’s one typical use for it:

perl cvschangelogbuilder.pl -output=buildhtmlreport

… note that the script can take a wee while to run (and may prompt to save your CVS password in a .cvspass file the first time round also), but once it’s finished, you should have a lovely shiny report. In the example command above, we’re electing to output as a manager-friendly HTML file. Everything’s there: who checked in what and when, how many lines of code you got (always an important metric, right?), pretty colours, the lot.

Job’s a good ’un!

For example, after a long day at my current contract, I needed a wee bit o’Java that would pad out an integer to a three-digit string value. Now, there are ways to do this with simple padding, length testing and sub-stringing, but this, I think you will agree, is much better:

String.format("%03d", someIntOrOther); // pads with length of 3

Eh? Eh? Great isn’t it! And the thing is, I just knew there was something like this out there, so rather than flail around in Google, I opted for a simple search (for “java padding”) at Stack Overflow, and collared this code in no time.

I ♥ the Stack Overflow.

(BTW, if you fancy this padding code, you can vote it up and find the whole question / discussion / bonkers rubbish answers here).

One of the common whinges about Eclipse as a development environment is that there is no decent cross-project / cross-workspace search. I know we Mac users can be insufferably smug, but I’m sorry, Spotlight really does the do here. I was searching for a constant—let us call it WINKLE—and out of the 200-odd classes in a particular project, I could not remember where it was. Go to the Spotlight bar in OS X, type in WINKLE. Narrow your search to your Eclipse Workspace folder if you like, and in a gnat’s fart, you are there:

Now I know you can trace call hierarchies in Eclipse, and that’s a really handy feature. But Spotlight rocks, and this is just one of the ways.

So here goes, a lightweight guide to logging in Java, seeing how logs are close to my heart. Of course, as with anything in Java, there is no One True Way, but this is as good as any (feel free to shoot me down in flames).

If you’re well-behaved when it comes to your Notes / Domino development, you use some kind of logging, even if it’s only during the debug phase of your development project. Domino provides a capable framework for this—NotesLog—and Julian Robichaux has gone one (thousand) better with his excellent OpenLog project.

Your Java code should be no different. OpenLog works for Java as well as Lotusscript, so you’d do well to use it in your Domino Java agents. If you’re coding non-Domino stuff though, you might want to consider one of the Java logging frameworks. There are a fair few, and it gets confusing when you see mention of log4j piled on top of talk about org.apache.commons.logging and the like.

In Java you have to justify everything

Being a lazy sod, I can’t be doing with all the advanced guff about appenders, custom configurations, different libraries, ya-da ya-da. I just want to be able to log some stuff somewhere consistently, and move on to the next problem. I tend to choose something that looks OK, and run with it. My current project has a fair few developers dipping in and out of it, with a number of possible forks possible downstream. To this end, I opted for the Apache commons-logging project as tiny layer above the venerable log4j framework. Here’s what the commons-logging wiki has to say on the matter:

If however, like the Jakarta Commons project, you’re building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can’t be sure what logging framework they’re going to want to use, then commons-logging might be useful to you.

Fair enough. Let’s go!

1. Add the commons-logging JAR to your project dependencies
2. Ensure relevant classes import the relevant packages (org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory)
3. Initialise your log^*:

   private static Log log = LogFactory.getLog(YOURCLASSNAME.class);
   Use the shiny new log in your code: 
   log.debug("WidgetOne fully instantiated; now populating WidgeTwo");
   

Simple! We’re using log4j as our implementation, which is arguably the most common logging package. If you want to pick up an example log4j.xml configuration, then this should do the trick (link to an annotated, teeny tiny XML file).

Silly footnotes

^* - You can be a little fancier here if you must, using reflection to grab the name of the current class, thus rendering your single line of code truly portable ^**.

^** - Oh all right:

String cn = this.getClass().getName();
System.out.println(cn.substring(cn.lastIndexOf(".") + 1));

getClass().getSimpleName();

Filtering

Logging is so prevalent in the Java world, that you may find that your appender of choice gets rather cluttered (tsk). If you wish for more purity in your console / log file / mail / whatever, then you can add <logger> entries in your log4j configuration to filter out the guff. For example, in our project we don’t care about messages from the Hibernate package, so this is what we do in our log4j.xml file:

<logger name="org.hibernate" additivity="false">
  <!-- ignore all but most serious messages from Hibernate -->
  <level value="error" />
  <appender-ref ref="stdout" />
</logger>

… This way Hibernate quietly sits in the corner unless it hits a major error. You can add more logger nodes for various packages, even down to the full class level. Alternatively, you can ignore excluding stuff, and simply do a filter which includes just your package (in this example, com.benpoole.winkle):

<logger name="com.benpoole.winkle">
  <!-- Print only messages of level DEBUG (or higher) for winkle -->
  <level value="warn"/> </logger>

Further reading

There’s a reasonable wiki page out there, all about setting up your log4j file. It also provides guidance as to how to convert an older-style log4j.properties file into its XML equivalent: Log4j XML Configuration Primer. The wiki goes on to detail the various Appenders you can use (e.g. file, console, SMTP…) and even sort of tells you about “additivity”.

In short, it tells you more than I. Enjoy, and log on!

1. Eclipse IDE for C/C++ Developers (78 MB) Uh huh. 78 meg? Wow, that’s pretty small.
2. Eclipse IDE for Java Developers (91 MB) Apparently this includes Mylyn, which is “essential”. Hmm.
3. Eclipse IDE for Java EE Developers (187 MB) ’Nuff said :-)

More seriously, the Eclipse platform is still my IDE of choice for Java development, and I enjoy working with it (so long as things don’t go wrong in the Eclipse Workspace). Time to get downloading!

(PS predictably, on twitter too!)

Update: actually, Mylyn really is useful!

 // Here we iterate documents in a view
 try
 {
 Document doc = view.getFirstDocument();
 Document docTmp = null;
 
 while (null != doc)
 {
 // Your doc processing code here
 
 docTmp = view.getNextDocument(doc);
 
 doc.save(); // assuming changes
 doc.recycle();
 doc = docTmp;
 }
 
 /*
 * Could do this in 'finally' if you like,
 * but you need to declare objects
 * outside the try… catch in that case
 */
 if (null != doc) doc.recycle();
 if (null != docTmp) docTmp.recycle();
 if (null != session) session.recycle();
 }
 catch (NotesException e)
 {
 // TODO error handling
 }
 finally
 {
 try
 {
 view.recycle();
 db.recycle();
 }
 catch (NotesException n)
 {
 // Don't care
 }
 } 

Hope this is useful for someone. Feel free to comment away and improve!