Did you read "Effective Java"? If you didn´t, you should: it is one of the greatest book about java i have read so far. The only problem with this book is that - over time - you tend to forget some of the invaluable advices, you get from it.
At least, this happened to me: I wrote some Abstract a few weeks ago, that used some template Methods to delegate to its implementations, little less obvious, but essentially just like this:

public abstract class AbstractFoo{
	protected AbstractFoo()
	{
	   initialize();
	} 
	// can be used to initially read state.
	protected void initialize(){}

Already know what kind of trouble i was going to face? Lucky you

Few weeks later, i added an implementation to the codebase, that used some File Object:

public class FileFoo extends AbstractFoo{
        private File file;
	protected FileFoo(File file)
	{
	   super();
	   this.file=file;
	}

I remembered, that for the reason of initialization, i already added a method i could use, to read from that file. So i made use of that:

protected initialize()
	{
		readFromFile(file);
		[...]
	}

I guess, you see the trouble here, don´t you? The member file is not yet initialized, when calling the method.

"Do not use non-final methods during object construction"

Even worse: i added a template method, that encourages to be overwritten. Stupid me.
That´s what i call a bug pattern

When it comes to profiling applications, one of the most important feature to me is the ability to focus on what is important. The problem with Memdumps and Thread-traces is, that you´ll immediately face much more information you can handle, and the tool´s ability of helping you on your way drilling down through the data is the killer-feature a profiler can provide.
After some good experience with JProbe, i came across YourKit and i am excited by its possibilities as well as its easy, intuitive and nice GUI. It seamlessly integrates with whatever your fav. JavaEE-Container might be, and it has many predefined filters to sharpen your view on code, you can control.
One flaw is in there. It assumes the JavaEE Container to be on the same platform in order to configure it automatically.

Never mind. It takes a minute to do it manually and have YourKit profile your remote unix-glassfish from Windows.

I am a JIRA fan and i hate TRAC. Tracs interface seems to be utterly useless and it is not easy to customize it without spending a significant amount of time for that.
JIRA is very different. Its interface is clean, flexible and you can easily create groups that have nothing more than a Type/Title/Text-Form to create an issue. I found that a very imporrtant feature as my old company used it in order to communicate within and beetween departments as well as with clients.

So how does all that relate to Thoughtworks´ Mingle ?

• Well, a coworker of mine - fighting with Trac again - asked, if JIRA had something like a TODO List;
• I asked myself, if the 'Issues' can be planned easily, or if i have to take an ms-project alike for that;
• and my Boss asks for Transparency with the department.

Well, a little too much for Jira, right? All of that can be done, i´m sure - but it will not be hassle-free. Admittedly, JIRA is much more, than a bugzilla like Defect Tracking Software, but i just did not feel like this was all i needed. Luckily, i stumbled upon Mingle. I just had a few moments yet to use it, but from what i´ve seen, it is incredible:

Clean interface, total customizability, easy data-im/export, release planning, Scrum´s Sprint Backlogs, SOtry-Cards as well as classic Defect Tracking and a WIKI with great reporting options !

Not, that any of this is absolutely unique, but i´ve never seen a Software that complete, yet flexible to do what i need it to.
If your looking for more than a issuetracker, you should consider it.

Note: Mingle is not free, as soon as your team get >5.

• Mingle
• Atlassian JIRA
• Trac

From now on, i´m going to release a few little spare-time-software projects. The first is a simple Wicket-Component written to integrate the famous Lightbox2 JavaScript into Wicket Components/Pages.

It can be found here

i fell over a subtle bug in Wicket-IOC, that causes RuntimeException when Wicket-Guice is used together with Guice-bound-Interceptors while Injecting non-Interface Classes.

While the above usecase is a terribly rare one, this problem shows that it is not always a good idea to copy a required lib to another package in order to have 'no dependencies' like guice did here. This way you have two CGLibs in memory and run into problems you would not have otherwise. (Those two CGLibs produce classes of the same name here)

Read details here:
https://issues.apache.org/jira/browse/WICKET-1162

If you´re into Hudson, take a serious look at this plugin. The time for an eclipse plugin like that has definitly come.