In a view of a Java developer, there are not a lot of new features. German readers will find at jaxenter a nice article with all new Java features.

The only one, which seems noteworthy, is the new toString() wizard:

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.

Luckily, there is a nice open source solution called XmlTask, which offers many possibilities to work with XML files.

1. Download the latest version of XmlTask from http://xmltask.sf.net
2. Create a task definition in Ant

   1 2 3 4

   <taskdef name="xmltask" classname="com.oopsconsultancy.xmltask.ant.XmlTask" classpath="./xmltask-v1.15.1.jar" />

3. Use it with the <xmltask> definition
   
   For example, read out the number of a specific node in the XML file:

   1 2 3

   <xmltask source="someFile.xml"> <copy path="count(//aNode)" property="numberOfNodes" /> </xmltask>

   Or change an attribute:

   1 2 3

   <xmltask source="someFile.xml" dest="toAnotherFile.xml"> <attr path="//aNode[1]" attr="enabled" value="true"/> </xmltask>

There are many other possibilites to work with XML files inside Ant. Check out the documentation at http://xmltask.sf.net.

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.

But fortunately, there is Groovy. Groovy is a scripting language, which runs in a Java Virtual Machine. And because of that, it can be easily integrated with Ant.

1. Download the latest release of Groovy at http://groovy.codehaus.org/Download
2. Inside the Groovy binary, there is a folder called embeddable. In this folder, there is a file called groovy-all-X.X.X.jar. Take it and copy it near your build file.
3. Create a task definition in Ant

   1 2 3 4

   <taskdef name="groovy" classpath="./groovy-all-X.X.X.jar" classname="org.codehaus.groovy.ant.Groovy" />

4. Use Groovy somewhere inside an Ant task:
   

   1 2 3 4 5 6 7 8 9

   <groovy> int i = 1 int numberOfIterations = properties["numberOfIterations"].toInteger() while (i &lt;= numberOfIterations) { properties["currentIteration"] = i ant.antcall(target:"execute.a.task") i++ } </groovy>

Isn’t that groovy?

Groovy integrated in Ant offers many possibilities, which can be read here http://groovy.codehaus.org/The+groovy+Ant+Task. I used for my little script the variable ant, an instance of the current Ant project and the properties map, which holds all properties inside Ant.

(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!

public class DemoApplication {
 
    public static void main(String[] args) throws Exception {
        DemoApplication calc = new DemoApplication();
        System.out.println(calc.divide(calc.add(17, 19), 2));
    }
 
    public int add(int i, int j) {
        return i + j;
    }
 
    public int divide(int i, int j) {
        return i / j;
    }
}

In earlier times, I stepped one step further to get into the method divide. Then I got the result of add(17,19) in my parameter.

But Eclipse is offering a better solution. In the Debugging Perspective, there is a view called Expressions. Just add a new expression add(17,19) and the Debugger is printing out the result.

The result is directly printed out:

A simple, but helpful feature in Eclipse!

I started about two months with working a little bit with OSGi. I want to write here these parts, which were unclear for me at the beginning. It should be an introduction for everyone, who has never heard about OSGi.

Okay, let’s start.

The setup of OSGi is something like EJB.

1. EJB has a specification from Sun.
2. OSGi has specification from the OSGi Alliance.
3. EJB need’s an application server as a platform (Weblogic, Glassfish, Websphere, JBoss, and so on) to run an “EJB” application.
4. OSGi need’s also a platform to run “OSGi” application. Like an application server, which is implementing the EJB contract, an OSGi platform implements the OSGi framework specification. Currently, there some OSGi implementation out there. The most known are Equinox, Apache Felix or Knopflerfish.

Okay, now, we know, how OSGi is built. But what does it? In one sentence, it is something like a JVM with some extra features. OSGi extends the JVM and a Java program is running on that OSGi Platform instead of running directly on the JVM. OSGi offers some advantages, which I will mention shortly.

 
(Source: http://de.wikipedia.org/wiki/OSGi)

The difference between a usual Java program (a JAR file) and an OSGi program (let us call that a bundle) are some information in the META-INF\MANIFEST.MF file. These information looks like:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Example OSGi bundle
Bundle-SymbolicName: ch.stefanjaeger.osgi.example
Bundle-Version: 1.0.0

That’s it. An OSGi program (called a bundle) is nothing more than a JAR file with the MANIFEST.MF. Now, you can run this bundle in an OSGi environment like Equinox or Apache Felix.

Okay, know, we come to the advantages of OSGi. The biggest advantage is the ability to run a bundle in different versions at the same time. For example, bundle A has a dependency to bundle B in version 1.0.0 and bundle C has a dependency to bundle B in version 1.1.0.

With the usual JVM, you get a problem when running A and C in the same VM. The JVM will take the first “B” in the classpath it found. This means, it is possible, that for C gets the files from B in version 1.0.0 (instead of 1.1.0), which could result in “MethodNotFoundException” and such stuff.

With OSGi, this problem doesn’t exists anymore. In the MANIFST.MF you can define all dependencies explicitly with the version. Following example means, that our bundle has a dependency to the Apache Commons Lang Package in version between 2.0.0 and 2.1.0.

Require-Bundle: org.apache.commons.lang;bundle-version="[2.0.0,2.1.0]"

The OSGi platform checks at the beginning, that all required bundles are available and solves the classpath problem for us.

Okay, we’re almost finished. There is one important point I want to mention. Packages are not “open” as usual in JAR files. If we want to make some classes accessible for other bundles, we do have to export these packages:

Export-Package: ch.stefanjaeger.communiction.interfaces

Of course, OSGi can do more than that. But for this introduction, I think, it’s enough

• Study Guide
  http://java.boot.by/scbcd5-guide/
• Free Training Test:
  http://www.sun.com/training/certification/assessment/

I also wrote some “Factsheets”, which I used to sum up all topics. Besides Factsheet 0, they can also be used as an assistance on the daily EJB 3.0 work.

• Factsheet 0 – some stuff, which is only for the SCBCD relevant
• Factsheet 1 – Stateful and Stateless Session Beans
• Factsheet 2 – MDBs and JMS
• Factsheet 3 – Transactions and Security
• Factsheet 4 – JPA, part 1
• Factsheet 5 – JPA, part 2

If you find any mistakes in the Factsheet, just let me know.