Java Performance

In the old days, there was much concern that Java programs were slow and could not complete with C or C++ programs. It seems that this is not as true any more. I just read a huge discussion on the topic. Here are some interesting points I came out with.

C has a small footprint. So if that is required, choose C. Java has a long startup time. This is the time it takes for the JVM to load and initialize. We are talking on the order of seconds here.

Direct machine access can be done with Java using JNI. However it is clunky. In C, direct machine access is natural. However garbage collection in Java is easier than C's malloc/free. Java also make parallel programming easier.

Be careful when you are comparing speed between Java and C programs. You must ensure both programs are using the same algorithm. You also need accurate stats to make a good comparison. As an aside, C# will normally be a little bit slower than Java.

Java 7

Java 7 is big. The Java Virtual Machine will support dynamic languages. Strings can be used in a switch statement. The JVM performance has been improved. A new garbage collector called the G1 is the source of the speed up.

There are other niche additions to Java in Java 7. For example, in the security world, there will be support for curve cryptography. Personally I care little about JVM support for dynamic languages. Java with its static typing is fine for me.

Gosling is Gone

James Gosling, creator of Java, has quit from Oracle. He announced this on his blog. Strangely enough, his blog has disappeared. I guess they chop your blog at Oracle when you leave.

Gosling did not provide a reason for leaving. Hello? Can you say Oracle acquisition? He is going to take some time off.

Word on the street is that the Java faithful were taken by surprise. Does this mean that Gosling will not be present at JavaOne? You got to go and find out.

Oracle Plans

Oracle Corporation has a number of plans for the future of Java. They plan to merge the HotSpot and JRockit JVMs into one product next year. They also will be supporting languages other than Java in the JVM. These will include Ruby and Python.

There is also talk that the Java SE and Java ME platforms will merge into one. Perhaps that means that mobile apps are becoming common. It is either that or mobile apps are not as important any more.

The JavaOne conference is going to be held in tandem with the OpenWorld conference. You can register and attend events at both conferences. JavaOne will now be held in the September time frame. I guess Oracle has decided what has the precedence. At least they are not ending JavaOne.

Object Database

I saw an advertisement while perusing a technical magazine. It was for an object database created by InterSystems. The product was called Cache. What caught my eye was the claim that it had technology to persist Java objects with a relational mapper.

The object model for Cache is based on the Object Database Management Group (ODMG) standards. It works with C++ and .NET as well as Java. The marketing boasts 5x the speed of normal relational databases.

Cache is meant for Rich Internet Application development. It uses an application server. However there are multiple ways to make use of the object database. You can use templated classes. There are also lightweight API calls for direct database access. Finally there is the Jalapeno technology.

Jalapeno stands for JAva LAnguage PErsistence with NO mapping. You create your Plain Old Java Objects (POJO) first. Then you use Cache to generate a schema to work with those objects. Cache has a library class to deal with the database. You can apparently just focus on your POJOs, and Cache will do the rest like magic.

Deploying Programs

I checked out Java in Easy Steps from the local public library. After scanning the table of contents, I jumped straight to the chapter on deploying programs. This is an area of weakness for me in Java development. There are two ways to distribute Java programs. You can do so as a desktop application, which will require the Java Runtime Environment to be installed. Or you can do so as a web page applet. The second option will require the browser to have a Java plugin.

When rolling out a Java program, like any other installation, you need to make sure the resources required by the program are installed. The main way to include all the files you need is with a jar. Jar is a utility included in the Java SDK. You can find the program in the Java bin directory. This program has a command line interface.

The output of the jar utility is an archive file. You can run the program contained in the archive using the Java interpreter. Here is an example to create a jar file:

jar cf dL1.jar dL1.class.

Once you have the archive, you can inspect its contents using the following command:

jar tf dL1.jar

You can extract the full contents of the jar file like this:

jar xf dL1.jar

Jar creates a META-INF directory. Within that directory is the MANIFEST.MF file, also created by jar. You need to manually add the entry point for the program on the bottom line of that file as so:

Main-class: dL1

To run the program contained in the jar, you can execute the following command:

java –jar dL1.jar

Build Tools

When I first joined our project, our build scripts were written in the Korn shell. Our Korn shell programmer quit after I joined the team. Thus began our build script Hell. The scripts worked fine when everything was as expected. However they would bomb at the slightest disturbance. We needed a full time guy to baby sit this fragile set of Korn shell scripts.

Eventually a bunch of Java programmers joined the team. They decided the Korn shell scripts had to go. Being Java guys, they turned to Ant to do the builds. The result was a bit more reliable.

The Java guys got bored after a while. They started looking for ways to improve the build scripts. Maven was cited as a cool build tool. There was talk about redoing the build scripts again. However the Java guys left the project before any progress was made on that front.

It might be a blessing that we never ported our builds to Maven. I just read a rant describing Maven as pure evil. The author recommends you code your own build tool from scratch. He advises you to use Rake or Ant if you want to utilize a package. However he abhors Maven.

Here are the reasons to avoid Maven. It has the worst configuration syntax. The documentation is bad or incomplete. Maven is not flexible. It also has a broken dependency management subsystem. Exercise extreme caution if somebody tries to port your build scripts to Maven.