I’ve been developing software for quite a few years now and I notice that sometimes I break the rules, those best practices that I know are right to follow.  With so many blogs, books and articles covering the best way to develop software, the temptation to do your own thing still can take over – even when you know it’s wrong.

Ashamedly, I know that I’ve broken these rules in the past, as I’m sure most software developers have.

This is a repost of my original article on JavaLobby

Test Driven Development

There’s no question in my mind that the best approach to developing any piece of code is to do tests first and then code. It focussed the developer in a different way than other approaches. You’ll find that you start a fresh project with good intentions and write your tests first. Then, as you get further along the way, you start to run out of time, so somethings got to give – it will usually be your tests.

There’s no excuse for this. All IDEs have JUnit built in to them and any developer with experience knows that it works. All developers who think that unit tests can be skipped should read Pragmatic Unit Testing. The authors put it best when they proclaim “unit testing means never having to say you’re sorry“.

Ignoring Broken Windows

Sticking with the Pragmatic Programmer series of books, one of the big lessons for software development is to have “no broken windows”. A broken window is a piece of badly written code that exists in your codebase. If the window isn’t fixed, then it will lead to other broken windows.

While I might not be the first one to pollute a codebase, I’m as guilty as that person for not fixing, or at least logging, the issue. I don’t know how many times I’ve gone through code, looking for where I need to add in my fix, and ignored rows of broken windows on the way.

Once again, there’s no excuse for this – I’m aware of the rule, I know that it makes sense, but I’m too caught up in getting my part done.

Mixed Up Spagetti Code

These days most of us declare the wonders of modular architectures – being able to seperate code down to bundles of responsibility and redeploy those bundles anywhere. So we create a bundle (or package) with UI responsibilities, and then we create another for logic. How many times have you seen that logic code starts to creep into your UI bundle? Of course this doesn’t become apparent until too late unless you’ve been following a test driven development approach, and have been testing anything that you can do on the UI through the logic layer.

Of everything on this list, this is the one that I hate the most, and as such is the one that I’m least prone to.

Diving Right Into The Code

It’s new project day, and you know you’re going to be using some cool technologies. Even if you’re using the same technology, at least it’s a clean slate. Nothing of the past three habits is going to get in the way this time. Or will it?

The tendency to avoid analysis, and dive straight into the code is common with all developers. It’s a natural thing as we like to get things running. It’s even excusable if you do a quick run through, take the lessons learned and then go through an analysis stage. But it’s the going back that’s the problem – once we’re in the code, we’re happy there.  Sometimes we sugarcoat this as an “agile approach” but is it really?

The Solution

The software industry would be in a much better state if we had a ready made solution to these bad habits. There’s a common theme through all of my failures above, and that is time. Doesn’t it look like I’m always up against the clock? Maybe that’s my fault for not giving clear enough estimates. But if I bump up an estimate to ensure I follow all these rules, am I just going to waste the extra time I’m given?

Of course there are things that can be done such as peer reviews, but nothing can beat good programmer discipline. Maybe we need to introduce some kind of hippocratic oath for software developers?

It’s amazing the things that are right in front of you that you don’t realise. VisualVM is probably the best example of this in the Java community. Everytime you go and update your JDK, you go straight to your IDE and capitalise on the new features provided. At least, that’s what I thought I was doing.

This is a repost of my original article up on JavaLobby

I first read about VisualVM in an article Geertjan Wielenga wrote back in February of last year when the tool had it’s third milestone release.  VisualVM could be the most important tool for Java developers, as well as being the best kept secret.  In a time where we’re still trying to prove that Java isn’t slow, this is the tool to help us keep the promise of performant Java applications.

Blog About VisualVM for a Chance to Win $500 USD

VisualVM In A Nutshell

VisualVM is a visual tool that integrates some of the commandline JDK tools and gives you powerful profiling capabilities. All for free! The commandline tools that it bundles up include jstat, JConsole, jstack, jmap and jinfo, which you get with your standard JDK distribution.

VisualVM will allow you to generate and analyze heap data, track down memory leaks, monitor the garbage collector and perform memory and CPU profiling, as well as being able to browse and operate on MBeans. While VisualVM runs on JDK6 it can monitor applications created since JDK1.4.

For me, these features are critical. Up to now I’ve been using commercial tools like YourKit to run performance checks on my applications, but now I can get equivalent functionality from an open source tool. And who knows the JVM better than Sun?

How To Get VisualVM

The best part of VisualVM is that it’s in your JDK bin directory already, if you’ve got any version of JDK1.6 since update 7. To run it, just click on the jvisualvm.exe icon.

All you need to do is click on the jvisualvm.exe and the application starts up. All Java applications running will be displayed on the right hand side navigation bar. Note that there is no need to register your application with VisualVM – it’ll appear automatically. You can also view remote applications in this navigator.

That unknown application (pid 5392) is Eclipse.

Using VisualVM

The list of features available is pretty impressive. VisualVM allows you to:

• Monitor application performance and memory consumption
• Monitor application threads
• Profile application performance and analyze memory allocation
• Take thread or heap dumps
• Analyze core dumps
• Save snapshots to analyze the application offline.

You’ll find instructions on how all of these features work in our previous post on the topic, as well as in the VisualVM getting started documentation.

An IDE Comparison with VisualVM

I wanted to do something different in my use of VisualVM, so I decided that I would do a comparison of the three leading IDEs. I did a fresh install of NetBeans 6.5.1 (JavaSE only version), Eclipse (for Java Developers) and IntelliJ IDEA (8.1.2).

The test is as follows:

• Run the Memory Profiler in VisualVM
• Create a new project in the IDE
• Create a simple class with a main method printing Hello World
• Save the Memory Profiler results
• Get a Heap Dump of the application
• Get information from the Monitor view in VisualVM
• Restart the IDE and using the CPU Profiler, perform the same steps in the IDE
• Save CPU Profiler results

I realise that both the CPU and Memory Profiling could have been done simultaneously, but for the purpose of this article I wanted to keep them seperate.

When I ran the IntelliJ tests I had to start it up with my own JDK rather than the IntelliJ one. I’m unfamiliar with the IDE, but I noticed it had to parse the files in the JDK when I created a new project with the JSDK.

Also, it’s fair to note that I’ve just downloaded the default distributions of these IDEs, without trimming them down to the minimum for Java development.

Heap Dump

I found the best means for comparison across the applications was the Heap Dump. This is really easy to do – at any stage during the application run, right click on the application in VisualVM and select Heap Dump.

The criteria I will compare here is the total bytes and total classes.

NetBeans Heap Dump

Eclipse Heap Dump

IntelliJ IDEA Heap Dump
IntelliJ :

• Total Bytes:   76,582,715
• Total Classes: 14,368

Eclipse:

• Total Bytes:   62,112,960
• Total Classes: 11,428

NetBeans:

• Total Bytes:   31,576,772
• Total Classes: 10,583

It’s clear here the NetBeans is the one that’ll use up less of the heap using half the bytes that Eclipse needs. IntelliJ seems to need a lot more.

The Monitor View is also interesting to look at as your application is running. Here I simply looked at the threaded local classes. Eclipse almost hits 25K, IntelliJ gets closer to 27K, while NetBeans stays below 20K

NetBeans Monitor View

Eclipse Monitor View

IntelliJ IDEA Monitor View

Memory & CPU Profile Results

I noticed that when I started profiling, that I needed to wait for instrumentation to be performed on the classes and methods. For the IDEs this took a significant, but not unreasonable, amount of time.
Memory and CPU profiling isn’t that useful for a comparison of products. Where profiling comes in handy is when you need to find where leaks exist in your application. Nevertheless, here are the results of the profiling for the IDEs.

It’s interesting to look at the common objects between the IDEs. For example, byte[] is heavily utilized in NetBeans, but to a lesser extent in both Eclipse and IntelliJ. We do see a significant use of char[] on all IDE’s

• NetBeans : 19.6% of memory
• Eclipse  : 31.6% of memory
• IntelliJ : 32.7% of memory

NetBeans Memory Profiler View

Eclipse Memory Profiler View

IntelliJ IDEA Memory Profiler View

The CPU profiling shows where the majority of time was spent in execution. There’s a big difference in the methods  that the IDEs spend there time on here

• NetBeans spends most time on org.openide.util.RequestProcessor$Processor.run() – 58.1%
• Eclipse spends it’s time on java.lang.reflect.Method.invoke() – 45.5%
• IntelliJ uses java.net.SocketInputStream.read() 38.7% of the time

NetBeans CPU Profiler View

Eclipse CPU Profiler View

IntelliJ IDEA CPU Profiler View
As a comparison, this tells us very little. But it is interesting to see the difference in how the IDEs work behind the scenes.

I must mention how easy this comparison was to do with VisualVM. I started it up before any of the IDEs and used the same instance all the way through, with the VisualVM registering each instance of the IDE automatically.

IDE Integration

Java developers are spoilt for choice when it comes to IDE’s. It can be uncomfortable to step out of them to do any programming tasks – we’ve gotten used to it. Thankfully, there are plugin’s available for all the popular IDEs, so you can work with VisualVM from the comfort of your favourite development environment, ignoring the command line.

NetBeans integration is an interesting topic when it comes to VisualVM. VisualVM is actually the profiler that comes as part of NetBeans by default. In it’s standalone format, it is a NetBeans RCP application, which can be further extended with other Netbeans modules.

Eclipse and IntelliJ IDEA integration is available here. MyEclipse 7.5 also comes bundled with VisualVM plugins. As an Eclipse developer, I was interested to see how this would work out – after all the tool is based on the NetBeans platform.

Eclipse Integration

First you’ll need to download the VisualVM Launcher plugin, and extract it to you Eclipse home directory. When you open the Run Configurations dialog, you will get a choice of application launchers. The default launcher to use can be changed in the Preferences page depending on what you’re running.

In my own setup I have chosen to use the VisualVM Launcher for Debug and the standard Eclipse Application Launcher otherwise. You can change these settings for applications, applets or Eclipse applications.

You will also need to specify a path to the VisualVM executable that you wish to use, and a path to the JDK.

That’s the point where Eclipse integration ends, as it launches up an instance of VisualVM automatically and you can work from there. Perhaps in the future there will be some way of hooking directly into my IDE instance and profiling from there.

Extending VisualVM

If all the features listed above aren’t enough for your own requirements, you can roll your own VisualVM plugins. There are a number of API entry points available, as illustrated in the diagram below.

The main entry points available are:

• Tab extension. By default, VisualVM provides tabs with labels such as “Overview”, “Monitor”, and “Threads”. You can create new tabs just like these. Optionally, your own tabs can be extendable so that others can plug subtabs into your tabs. Your tabs can either be available for all data sources in VisualVM or to specific types of data sources.
• Subtab extension. Within tabs such as those listed above, you can provide new subtabs. However, this is only possible if the tab has been defined to be “pluggable”, which is explained below. The following tabs are all pluggable: “Overview”, “Monitor”, “Threads”, “Heap Dump”, and “Host”. When you create a new subtab, you can specify its position in relation to the other subtabs within the tab. Subtabs can either be available for all data sources or for specific data sources.
• Menu extension. A data source, and its subnodes, can have one or more menu items added to their contextual menus.
• Application type extension. By default, all applications visualized in VisualVM are treated equally, that is, they all have the same icons and tabs, except if a plugin is provided to provide additional functionality. You might also want to provide functionality for a specific application, which means that you would need to define a new application type. You can do this to do something as simple as provide a distinguishing icon for a running instance of your application. Alternatively, you might want to provide a lot of functionality, including graphs, to show the processing of your specific application.
• Data source extension. The “Application” data source is only one of the types of data sources that can be monitored and managed in VisualVM. Another of the data sources is the “Host” data source, which lets you monitor and manage local and remote hosts. You might want to create new data sources, in situations where you want to monitor and manage a type of data source that VisualVM does not cater for by default.

There’s a detailed page on the VisualVM site showing you how to create your own plugins for VisualVM.  It seems pretty straightforward, especially if you are familiar with the plugin development approaches in NetBeans or Eclipse.  And there are quite a few plugins available already through the VisualVM Plugins Center. To see these go to Tools/Plugins.

Considering how easy it is to get VisualVM (you have it already), and the extensible platform that it’s built on, surely this will become one of those tools that you can’t do without. I’m impressed with the way that it just picks up the applications that are running, instead of having to register with the profiler. In theory, you could have it running in the background all the time, while you perfect and relaunch your Java application.

It’s something that you probably haven’t taken much notice of before, but it’s well worth taking it for a run and seeing if it helps you spot any weak performance areas in your application.

Twitter has become a fantastic tool for me to keep up with what’s going around in the Java and Eclipse communities. This is all down to following the right people. Here I’d like to share my list of the top 10 twitterers with you.

Follow The DZone Team
You can get most of the DZone team on Twitter already.

• @dzone
• Rick (@RickRoss)
• Matt (@mpschmid)
• Amy (@greenar)
• Kirk (@pragkirk
• James(@dzonejames)

10 ) Martin Fowler @martinfowler

Form an overall view of software development, there’s few better people to follow than Martin Fowler from Thoughtworks.
9 ) Robert Martin @unclebobmartin

Great to follow for thoughts, advice and articles on software craftsmanship and best practices.

8 ) Adrian Colyer @adriancolyer

As CTO at SpringSource, Adrian is well worth following to keep track one of the most popular Java frameworks.

7 )Kent Beck @KentBeck

Kent Beck is well known as the author of Extreme Programming. It’s interesting to watch what’s he’s up to at the moment with his frequently updated feed.

6 )Tim O’Reilly @timoreilly

Founder and CEO of O’Reilly media, Tim always tweets interestingand insightful news and articles from around the web.

5 )Neil Bartlett @njbartlett

For more Eclipse and OSGi related musings,tips and articles, Neil is a great person for your following list.

4 ) Adam Bien @AdamBien

As a Java champion, Adam is a great person to follow. I’ve been keeping up with all the news from this week’s JAX conference by following him on Twitter.

3 )Alex Miller @puredanger

Alex’s articles are always well received by the Java community, and when it comes to Java 7 coverage, Alex is unmatched! I’ve found loads of interesting links from following his @puredanger Twitter feed.

2 )Chris Aniszcyk @caniszczyk

Chris is another guy who really clicked with Twitter in the Eclipse community. He put together this page for all Eclipse twitter-ers to add their tags, and be followed – genius! You’ll also get loads of Eclipse tips through Chris’ feed, along with news from EclipseSource.

1 ) Ian Skerrett @IanSkerrett

Ian is Director of Marketting at the Eclipse Foundation. If you want to keep up to date with what’s going on in the Eclipse community, Ian is one of the best people to follow. He has really embraced Twitter as a means of communication and marketting. His re-tweets are always relevant. Ian was also responsible for taking tweeting to new levels at this year’s EclipseCon, by organising a “bird’s nest” and a screen showing all conference related tweets.

So that’s my list – you can follow me on Twitter as @dzonejames. There’s no doubt that I’ve missed some people who deserve to be in a top 10 list. It’s your job to let me know who!