After startup, you have to select your index. For this example, I created a test index with one file. It’s content is “this is a lucene test”. I used the StandardAnalyzer, which uses the WhitespaceTokenizer and filters out all tokens less than 3 characters and stop words. This will result in an index of the terms “lucene” and “test”.

In the register Documents, you can browse through all documents. Because we only have one file in our test index, we can directly jump to document 0. In the “Brows by term:” panel, we can browse through all terms, which are “lucene” and “test”. Very useful, to analyze the index for a specific document.

Also very interesting is the register Search. I typed in the phrase “this is a lucene test”. In the “Query Details” panel, we can see, that the query will be “lucene test”. The reason is simple. Every query get’s also analyzed by the same analyzer, which is used for building the index.

If you are using Lucene, just try Luke out. You can start it with Java Web Start from here.

To analyse this log file, there is a nice tool called GCViewer, which can be downloaded from http://www.tagtraum.com/gcviewer-download.html. GCViewer is able to display the memory usage of the application based on time and old/young generation heap space.

First of all, the GCViewer displays the GC log from the time on where the JVM has started. This is mostly not very useful. Just right click on the top of the diagram and enable the start time of the log.

What kind of GC exists and how to optimize them, can be read from http://www.javaperformancetuning.com/tools/gcviewer/index.shtml. In this post, I will just tell you something about the GCViewer itself.

GCViewer creates two parts in the diagram. These parts are just logical and shows, how big the young and old generation heap space of your JVM are.

• The orange part is the young generation heap size.
• The purple part is the old generation heap size.

Every time the old generation heap size reaches it’s maximum, a full GC gets performed. A full GC is a vertical, black line in the diagram. (Remember: a full GC stops for a short time all activities of the JVM and cleans the old generation heap space. It’s very important to know that the bigger the heap size the longer the duration of a full GC!)
The duration of the GC is displayed as the green line at the bottom. You can see in the picture above, that the full GC consumes much more time than the young generation GCs.

I can recommend to log in critical environments your GC activities. If you run into som performance issues or response problems you can easily search for the reasons. It is a completion to the usual log file.

(ArgoUML from http://moose.unibe.ch/tools/codecity)

I couldn’t wait to visualize our current software project. First of all, you have to create a MSE file of your code. The MSE file as a generic file of your source code. This is done with iPlasma, as described here http://moose.unibe.ch/news/iplasma-to-moose-screencast.

After you have created an MSE file, you can now visualize your code with Code City. Just download it from http://www.inf.unisi.ch/phd/wettel/codecity.html, run it, import the MSE file and create your city. Enjoy!

For better code analysis, I changed the configuration of the “buildings” in my city. I changed the width and length of class element …

… to a linear mapper based on the lines of code.

Code City is very helpful to compare different parts of the application and to just visualize the software!

Just open the Team Synchronization Perspective, open the View’s menu and choose Schedule…

Define the time schedule and press okay. That’s it.

Now, you’re almost always up to date!