Simon Brown's Blog

February 2005 Archives

JProfiler mini-review

I first came across JProfiler last year, when Sam and I were looking for a Java profiling tool that would run on Mac OS X. Surprisingly, this is harder than you'd imagine! Sam downloaded JProfiler, took it for a test drive and was impressed so much that we even talked about it in our J2EE on Mac OS X presentation. I've just revisited JProfiler, so thought that I would write a mini-review.

Core features
There are several profiling tools available on the market, such as JProbe and Optimizeit, and to be fair, they all kind of do the same thing. Okay, that's a massive over simplication of a very complex technology space, but the core features that most end-users are intested in are the same - thread monitoring, deadlock detection and memory/class instance monitoring. Here are a couple of screenshots of these key features from JProfiler running on Mac OS X.

Ease of use
One of the things that really strikes me about JProfiler is that it's so easy to use. The main window is simple and intuitive, allowing you to quickly navigate between the different views on offer. Filters are also very straightforward and provide a way to focus on a specific set of information.

Integration
JProfiler integrates with most of the popular application servers and, through the integration wizard, profiling a J2EE application is very straightforward.

After downloading and installing JProfiler, I had it integrated and profiling applications on Resin 2.x (Mac OS X), Tomcat 5.x (Windows) and Oracle 10g application server (Windows). All of this took about 20 minutes, which is a great testament to it's ease of use.

Summary
Although I've only been evaluating JProfiler for a short amount of time, I really do like it. For me, the real plus points are as follows.

• Easy to use.
• Easy application server integration.
• Runs on Mac OS X.
• Cost - it's one of the Magic 500$ java products.

Collections.unmodifiableX()

I just got bitten by the collections framework. I always thought that the Collections.unmodifiableX() methods returned an unmodifiable copy of the supplied collection, like a shallow copy. This is useful for getter methods where you want to return a copy of a collection to a client class so they can't directly alter the contents of that collection. This enforces encapsulation and ensures that clients use the methods that you have specified to manipulate your data.

But the Collections.unmodifiableX() methods don't work like that. Instead, they present an unmodifiable view of the specified collection. If you modify the underlying collection, this shows up in the unmodifiable view too. I won't be making that mistake again. To make a shallow copy of a collection, you can either use the clone() methods on the collection implementation classes or construct a new list/set/map, passing the original collection as an argument to the constructor.

It pays to read the javadocs, but without a unit test I would have spent even longer hunting this problem down.

This work is licensed under a Creative Commons License.