Category Archives: Know Your Tools

Get More Information from Windows Task Manager

Every once in a while I’ll find I need to force close a Java application.  So I open up the task manager in Windows, only to find…

java processesThe names are all the same, and the descriptions don’t help very much, either.  I can sometimes know based on the memory footprint, but that’s too much of a guess for me.

I don’t know about you, but I feel like I’ve murdered something innocent when I force close an application that was working just fine.

So the problem here is a lack of information, which we can rectify by going to “View | Select Columns…” and adding the column “Command Line”, which will display “The full command line specified to create the process.” – Quote Source

This will often give you enough added information to determine which application is represented by which process.

java processes - with command line

Quickly Navigate to a Package in “Package Explorer” in Eclipse

Often while working on a project, I will want to navigate to the same package that a class I’m inspecting is defined in.

I may want to get a better feel for what a class does / where it belongs, or want to add a new one in the same location, or various other reasons for wanting to do this.

The way I’ve always done this is the manual way.

“This class is defined in the ca.tu.horizon.consumer… ok ca – *click* – tu – *click* – horizon – *click* – consumer – *click*, there we go…”

However I just came across a very nice way of instantly getting there from within the hover tooltip that displays the package.  This is probably already known by most of you, and I’m a little mad at myself for taking so long to find this out, but you can just click on the package you want from within the tooltip!

1: In the hover tooltip, click on the package level you wish to navigate to

Package Nav 1

2: Click on the package icon

Package Nav 2

3: You’re brought to the corresponding package!

Package Nav 3

Excluding Folders from Sublime Text 3’s “Find in Files”

Note: Scroll down to quickly find the solution.


Today I needed to configure an instance of JBoss to connect to a postgres DB.  I remembered that I’ve done it before, but couldn’t remember much more than that.  So I thought I would fire up Sublime Text and take advantage of its “Find in Files” feature that, like many other programs that share similar functionality, will search within a given set of directories for a pattern.

It worked very well except there was a lot of noise in the results.  Turns out JBoss keeps a history of its configuration in a subdirectory.  The numerous copies upon copies of the same configuration files were slowing down the search and causing the same results to essentially repeat themselves.

In the GUI, when you go to add to your “Where” clause, telling Sublime Text which folders to search, there isn’t an obvious option to exclude specific folders.

SublimeFilterOptions“Add Exclude Filter” seems like a perfect candidate.  It will let you filter out files that you want to ignore, such as “*.log” to ignore all log files.  But what’s not immediately obvious is the pattern to ignore folders.

The Solution

Using a Linux style forward slash to denote directory structure, you can simply make use of the same asterisk to make it a pattern.  So to exclude every occurrence of the “standalone_xml_history” folder, the pattern becomes:


And to negate it, meaning to exclude that folder, simply add a dash, just like a normal negating filter.


So my entire “Where” clause to search through JBoss config files ended up being the following:


Rapidly Changing Between Mercurial Clones. Or, How I Went Crazy with Mercurial Power.

Update: To be clear, the below “solution” is not recommended.  This is just me fooling around with Mercurial, and being impressed with just how well it worked anyway.  Instead, please compare the different approaches to branching in Mercurial, and choose something well accepted.  Consider reading A Guide to Branching in Mercurial

The coding environment at my work makes heavy use of Mercurial clones to manage changes in team development.  If you’re going to fix a bug, or add a feature, you clone the production repository and place all of your code in the clone.  Continue forking as needed.

Repo Figure 1

The reasoning here, is to allow developers to maintain different branches, while simultaneously making QA easy.  See this workflow.

Also, note that the “Sub Feature” repositories are a little extreme.  It’s typically just the one level with separate repos for entire features and bug fixes.  The only time you see more levels is when there’s a whole team working on an individual feature and they want a shared repository to merge their stuff before it goes up the chain any further.

The main issue with a cloning work culture vs inter-repository branching or merely attaching patch files to the issue tracker, is that it’s tedious to manipulate your working directory that your IDE points to.  When I finish one bug, and am now onto the next, I have to somehow point Eclipse at the new source folder.  Or, I have to swap the source folder out with the new clone’s tip so I can begin working.

The reason for that is we have to keep our fixes / features isolated from one another, we don’t know which work effort will get past QC and into stable.  So by keeping them isolated, the build manager can instantly blow away the QC merge and make a new one with a new set of fixes and features added in.

Well, I didn’t want to point Eclipse to a new source folder each time, there’s no easy built-in way to do that.  I also didn’t want to manually swap out the code from one repository for another.  I wanted a quick and easy way.

My first thought was that since the the entire repository is inside the .hg folder, I could simply zip it up, place the .hg folder from the new repository in it’s place, and do a clean update to get the working directory in proper order.  It worked ok…. kind of.

Each time I wanted to work inside a different clone, I would have to do the following (after I acquire the new clone’s .hg folder):

  1. Zip up the current .hg folder to something like .hg.stable.7z
  2. Delete the current .hg folder
  3. Place the new .hg folder in place of the old

But then I had a crazy idea!  What if I use Mercurial to place the .hg folder itself under source control?!  That’s just too crazy, right?  Nested source control?  I agree, it’s strange.  But it actually works pretty well.  In the nested repository, I control the former via branches.  So I have a branch that tracks stable, one that tracks an individual bug, etc.

This allows me to essentially (and invisibly) force the workflow of branching into one of cloning-only.  A quick update and my work repository is at the state I want it to be in.

In practice the repository that controls the other ends up looking like this:

Repository repository

So when I am supposed to fix a new bug, and keep my changes isolated in a new clone, I can use this repository to revert the other one back to stable, do my work, commit it, and then come back to this one, and commit the repository itself into a new branch.

You can see in the image above where I’ve done that numerous times.  It splits off.  I can also quickly revert back if I want.  For example, if I ever get around to finishing that JSF and Richfaces Upgrade.

I still believe this is crazy, but it’s just the point I’m currently at on my quest to find the best way to go about this whole thing.  It’s fun to experiment.

repository new files at point

Know Your Tools: A Crash Course on Mercurial Patch Queues

Imagine that you just made and committed a new feature, and are halfway through your next super awesome feature when catastrophe strikes!  There’s something wrong with your previous feature that was just committed!  What do you do with your current uncommitted work?  You could shelve it, you could create a separate repository, or you could simply carry on and make note of the problem, promising to fix it later.  You have numerous options.

Let me introduce you to another option: “Mercurial Patch Queues!” he shouted with unmatched enthusiasm.

If you had done this local work as patches instead of commits, you could turn your unfinished working directory changes into a new patch, pop it off the applied stack (out of the working directory), fix your previous patch, re-apply the working directory patch, and then carry on with the work you were in the middle off.  Since you modified the patch itself, it’s as if your work was extra perfect the first time around.

In general, making use of these patches will allow you greater control over your changeset history.  You can think of it as a private mutable history that you’re free to manipulate however you like before you transform it into the normal shareable state.  Allowing you to get your changes just right before committing them, but still giving you advantages of source control.

Another use-case would be temporary “checkpoints”.  Let’s say you’re coding, and you want to save your current state, to protect yourself from future blunders, but this effort isn’t done yet and you don’t want to pollute the changeset history with numerous commits.  You want one commit that contains all of your related work.  For this, you can create a patch of the working directory.  If you’ve made a patch, and then later screw up, you can revert your code to the patch, just like you would a previous changeset.  So if you screw up later, you can revert to the patch that was made and try again.


Enabling the Extension:

In your mercurial preferences file: add

[extensions] =

And then check it’s working with “hg help mq”

C:UsersmurchDesktopNew folder>hg help mq
mq extension - manage a stack of patches

This extension lets you work with...
Creating a Repository With a Patch Queue – “hg init –mq”:
  1. hg init (if it’s already a repository, skip to step 2)
  2. hg init –mq (Two dashes.  Enables the patch queue functionality in the given repository)
Creating a New Patch – “qnew”:
  1. hg qnew patchname.patch
Update the Patch With Your Work – “qrefresh”:

After making some changes in your working directory, you can use qrefresh to update the topmost patch so that it represents all of your changes.

Note: If your change includes things such as adding a file, you still use the same “hg add” command and then you would use “qrefresh”, so that the change in the patch is “add this file with these contents”.

If you want to apply the changes to a patch that isn’t the topmost patch, you can simply make use of qpush and qpop until the desired patch is at the top of the applied patch stack, and then use qrefresh.

Note: Try to rearrange the patch stack before you make your local changes, otherwise when you go to rearrange with qpop and qpush, you’ll get a message like so: “abort: local changes found, refresh first”.  You can force the operation with the -f flag, if you really need to.

Manipulate the Patch Stack – “qpop” and “qpush”:

When working on multiple simultaneous patches, these allow you to manipulate the currently applied patches in your working directory: qpop takes the latest applied patch out of the working directory, and qpush will apply the most recently popped patch back into the working directory.

Make use of the -a flag to push or pop all patches.

Delete an Unwanted Patch – “qdelete”:

You can use qdelete to delete an unwanted patch by name.

Convert a Patch Into a Normal Mercurial Changeset – “qfinish”:

You can use qfinish to convert an applied patch into a normal revision in the changeset history.

Convert a Changeset Into a Patch – “qimport”:

The exact opposite of applying a patch to the changeset history is to take a specified revision and convert it into a patch.  You can do this with qimport.

Note: You can only do this if Mercurial considers the changeset to be mutable.  Which more or less means you haven’t sent that changeset off anywhere, such as with a push.

Sources and Further Reading:

(HG Book – Managing Change with Mercurial Queues)

(Why would I want to use MQ?)


Know your Tools: An Introduction to Eclipse Templates

How often do you find yourself writing the same small piece of code over and over and over?

Never, because I follow the D.R.Y. methodology, or “Don’t Repeat Yourself”, so I-

Let me stop you right there.  I mean really small pieces of code.  Things like this:

System.out.println( message );

That’s a good couple dozen keystrokes, and I’m positive you write other recurring code snippets over and over.  For me a common one is a null and empty check on Collections:

if( CollectionUtils.isNotEmpty( bar ) ) {
	//Do some stuff

Let’s go back to the print line example and see how we can speed that up, using a built-in template. In Eclipse, simply type “syso” and then hit the content assist shortcut (ctrl + space). Eclipse will replace the “syso” with the only named template that has a match in its name, which is the above print line code.

To more easily see what’s happening, hit the content assist shortcut first, and then type “syso”.  First, you’ll see the familiar dialog pop up:

content assist

Then, while typing “syso”, you’ll notice the options fall away as Eclipse filters out options that don’t match, and you’ll be left with one option, a template:

content assist filtered

That template is then used to generate code for you.

Built-in Templates

There are numerous templates already available for you.  Such as quickly generating a for-loop.

content assist for loop

Hint: Hitting ctrl+space a second time will show you just templates.  

Writing Your Own

For when the built-in templates have failed you and there isn’t one that does what you want, you can write your own.  For example, the second code snippet at the beginning of this post makes use of the class “CollectionUtils”, which is an Apache Commons utility class.  There wasn’t a built in template for that.  So to make it, go to:

Window -> Preferences -> Java -> Editor -> Templates

preferences templates

Click on “New”, and create whatever template you like!  Here’s mine to check Collections for null or being empty:
custom template creation

Hint: “Insert Variable” can help you figure out those “${…}” values.

Which is now in the content-assist window and will allow me to rapidly check future collections before I begin to use them:
custom template in action

In Conclusion

Using templates, both built-in and custom, can save you a lot of time and keystrokes.  Try ’em out.