Class file demand for which Java version

Someday back I got a call from my roommate's friend asking about that he has moved some class files from one system to other and now those class files are not running. I guess he got those class files from somewhere and he has no idea about which version of JDK it will run.

It's not such a tough job to find out that which version of JDK your class file is demanding. What we need to know is the format of class file and rest is like in your hands. Just look at the code for getting more clear picture.

import java.io.*;
class CheckClassFileFormat {
public static void main(String[] args) throws Exception
{
int magicNumber;
int minorVersion;
int majorVersion;
// and many more
DataInputStream data = new DataInputStream(new FileInputStream(args[0]));
magicNumber = data.readInt();
if(magicNumber !=0xcafebabe) // why 0xcafebabe.. read it, its so funny
{
System.out.println("Not a correct class format");
System.exit(1);
}
minorVersion = data.readShort();
majorVersion = data.readShort();
String version ="no version";

/*The Java virtual machine implementation of Sun's JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. Sun's JDK releases 1.1.X can support class file formats of versions in the range 45.0 through 45.65535 inclusive. Implementations of version 1.2 of the Java 2 platform can support class file formats of versions in the range 45.0 through 46.0 inclusive.*/

if (majorVersion < 48) {
version = "jdk1.3.1";
} else if (majorVersion == 48) {
version = "jdk1.4.2";
} else if (majorVersion == 49) {
version = "jdk1.5";
} else {
version = "jdk 6";
}
// can follow up the same line for new releases.

System.out.println(args[0] + ": correct jdk version is " + version);
}
}
Just pass the classfile (like Test.class) in argument and we get to know on which JDK it need to run :)

String vs StringBuffer vs StringBuilder

Let me first tell you what is StringBuilder. StringBuilder is a class analogous to StringBuffer added in JDK 1.5. This class is designed to use in place where StringBuffer is used by single thread(like in most of the cases). According to documentation, StringBuilder should work faster than StringBuffer. So " thread unsafe, fast".

I was reading one of the posts of orkut Java community asking "what is this capacity in StringBuffer and even we can add two strings from String class why to go for StringBuffer". Valid question ! GC need to work little more in case of String, but thats fair. As a java wellwisher let me try to do some publicity of Java API :D. And here it goes:

No don't use String class for concatenation operation, always use StringBuffer/StringBuilder and let me tell you why ?

This is a simple Java code for string addition in String and StringBuffer:

class StringTest {
public static void main(String[] args)
{
String s = "just a string";
s = s + "add me too";
System.out.println(s);
/*
StringBuffer s = new StringBuffer("just a string") ; //StringBuilder s = new StringBuilder("just a string");
s = s.append("add me too");
System.out.println(s);
*/
}
}

Alright, now have a look on the bytecode of this program(don't be panic).

>> javac StringTest.java
>> javap -c StringTest

Compiled from "StringTest.java"
class StringTest extends java.lang.Object{
StringTest();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object.":()V
4: return

public static void main(java.lang.String[]);
Code:
0: ldc #2; //String just a string
2: astore_1
3: new #3; //class java/lang/StringBuilder
6: dup
7: invokespecial #4; //Method java/lang/StringBuilder.":()V
10: aload_1
11: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/
String;)Ljava/lang/StringBuilder;
14: ldc #6; //String add me too
16: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)
Ljava/lang/StringBuilder;
19: invokevirtual #7; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
22: astore_1
23: getstatic #8; //Field java/lang/System.out:Ljava/io/PrintStream;
26: aload_1
27: invokevirtual #9; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
30: return

}

Just see line no. 11. Interesting, the plus sign we used for addition is not as innocent as it looks. String itself use StringBuffer(StringBuilder) to add two strings and hence taking much more time than normal append operation done by StringBuffer. Let me give you more evidence, run verbose option and check the time

>> javac -verbose StringTest.java

and check the other one, that is, with StringBuffer one.

You can clearly figure out the time difference and make a try with StringBuilder, time should reduce furthermore.

So, how is my publicity :D

Bug Patterns in Java

An attitude of solving the problem when it aroses is always be so called " a lovely" behaviour of Software Engineers and so I. Most of us love this and never bother to read book :) . Anyway with a half-hearted mind, I start reading a book "Bug Patterns in Java". In the first glance name of the book suprised me becasue I never before saw a language book which discuss only about bugs. I liked the title and started the book. Also, as java becomes a mature product, a maturity of something around 11-12 years, resolving any bug of this language is a nightmare's job.

Author,Eric Allen started with a very macro level saying every bug falls under a pattern and if not then go ahead and make a pattern for it :). Let me tell you about one of the most common patterns. One pattern call "Rogue tile", the cause of this bug is we do copy paste of code, bug get fixed in the orignal copy and we forget to fix it into the copy paste code. So funny, but yes this is one of the most common errors we used to do.

So far, so good. Hoping for something great out of it :)

JDK 1.7 - Whats New ?

I remember the exact date when Mustang got released. Mustang is going great because of it's deadly features like JS support, Annotations and many more.

Moving forward to JDK 1.7-Dolphin which has a expected release in 2008! Whats new ?

I am making a complete presentation on Dolphin and will upload it soon ! Proposals are:

1. SuperJAR's - this is something really cool

2. Co-bundling with other language interpreter like JRuby, Jython.

3. Closures in java - something in one line we can understand local variables for a function - kept alive after the function has returned

4. More enhancement with Java Persistence API

and many more ...

The new JDK comes into a new flavor of open source, so get ready >