I am never convinced about hard coding usernames and passwords inside application source code that is then deployed into a number of locations that are under less control than the configuration file could be - Yes I know that in a lot of clients neither the file or the Java will probably be secured. The Java source can be either reversed quite easily or a string utility or binary editor used to extract the password quite easily. Of course a configuration file does not need to be reversed!, it can be simply read if access is gained. BUT, as I am not an expert in Steve's Java areas it is harder for me to know about the whole security landscape used. My opinion would be that if presented with two choices of either hard coding the password in a configuration file or in the source code, I would choose the configuration file as there are better potentials for securing the file as there is a better chance of centralising it rather than having the password in multiple deployments of the Java classes. That said neither solution is great for strong security - This is no reflection on Steve's example.
If you are concerned with good security then look at password repository solutions, or do not store the password, have it passed in if possible or use solutions such as LDAP. Of course always use the least privilege principle. This means ensuring that the privileges assigned to the user who's password is stored or hard coded is set to the minimums possible, this is sometimes hard to do especially with existing systems but it is worth the effort. If you seriously reduce the privileges to only what is necessary you lessen the risk of an attacker being able to do anything with an account if he learns its password.