Normally we would expect a NullPointerException everytime we access a method or a member variable through a 'null' reference. But, interestingly, there is one case in which you can ! (?)
Take a look at the following Java source code for NullTest.java
public class NullTest {
public static int count = 0;
public static void main(String[] args) {
System.out.println("Will this be a NullPointerException? ");
NullTest app = null;
app.count++;
System.out.println("Or will it print the count: " + app.count);
}
}
Output of the above program
The static variables are associated with the class and not with any specific instance of that class. So one can access static member variables or methods even through a 'null' reference !! Ideally use the class name and not the instance name to refer to them as follows.
//
NullTest.count++
//
With many years in the software development, we all have some fire side stories to share. These range from deleted files, chasing elusive bugs, that all night effort to meet a deadline. In the following series, I recollect some of these tales. The present article tells the story of how a HashMap randomly made the objects disappear!
We had a HashMap which held a few entries with keys of type Person and the values of type String holding company's name. After adding these entries to the HashMap we noticed that some of them randomly disappeared - that is - we could not retrieve the Company Name String (value) even passing the Person (key) that was used to add the entry!
I have included the sources of Person.java and HashMapStore.java for your debugging pleasure :-) Sleuth on - solution is at the end.
import java.util.HashMap;
public class HashMapStore {
public static void main(String[] args) {
Person sai = new Person("Sai Matam", 35, "Coding");
Person bill = new Person("Bill", 45, "Fishing");
Person don = new Person("Don", 55, "Reading");
HashMap < Person, String > hashMap = new HashMap < Person, String > ();
hashMap.put(sai, "Grand Binary Inc.");
hashMap.put(bill, "Super Coders Inc.");
hashMap.put(don, "Great Software Inc. ");
String saiCompany = hashMap.get(sai);
System.out.println("\nSearch for sai's company: " + saiCompany);
String processedName = sai.getName().replace(' ', '_');
sai.setName(processedName);
processedName = bill.getName().replace(' ', '_');
bill.setName(processedName);
processedName = don.getName().replace(' ', '_');
don.setName(processedName);
saiCompany = hashMap.get(sai);
System.out.println("Let's search for sai's company again: " + saiCompany + "\n\n");
}
}
public class Person {
private String name;
private int age;
private String hobby;
public Person(String name, int age, String hobby) {
this.name = name;
this.age = age;
this.hobby = hobby;
}
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return this.age;
}
public void setAge(int age) {
this.age = age;
}
public String getHobby() {
return this.hobby;
}
public void setHobby(String hobby) {
this.hobby = hobby;
}
public int hashCode() {
return name.hashCode() + age + hobby.hashCode();
}
public boolean equals(Object otherObj) {
Person otherPerson = (Person) otherObj;
return ( name.equals(otherPerson.getName()) &&
hobby.equals(otherPerson.getHobby()) &&
age == otherPerson.getAge());
}
}
Initially I suspected the hashCode() or equals() implemenation in the Person class. But they were okay. The culprit was in the HashStoreMap.java where the keys of the Person objects were being modified after they were inserted into the HashMap !!!
When the Person object was modified its hashCode() changed. So the next time HashMap searched for this key it looked under a different hash bucket and hence could not find the entry. So it returned 'null' !! Mystery solved.
Never change the object used as a key in a HashMap. It would be a good practice to make this key object immutable.
If you liked this article then please vote for this article by clicking on the green up arrow.
Your feedback is most valuable. Please use 'comments' or an e-mail to saimatam (at) yahoo (dot) com
With many years in the software development, we all have some fire side stories to share. These range from deleted files, chasing elusive bugs, that all night effort to meet a deadline. In the following series, I recollect some of these tales. The present article tells the story of how beautifying the code introduced a bug into a program!
I was helping my colleague debug a highly complicated algorithm. He told me that the algorithm had been working well in the morning and by afternoon, after he had beautified the code it stopped working! This seemed bizzare! Can code beautification and formatting introduce a bug? It semed very unlikely. I was sure that my friend had altered the code accidentally while beautifying!
I spent many hours tracing the algorithm and it seemed to be correct. Then I suspected the seed values to that algorithm. Long story short - I have extracted the problem into the following piece of code. Here is the program and its output. In the program you see the plain array of integer values. You also see another array of the same integer values - only this time - the numbers have been properly aligned one below the other. Notice the output - how come the values in the beautified array print different values!
ZERO padding the integers caused them to be interpreted as Octal constants! The value 011 in octal is 9 in decimal. Mystery solved!
The dudes and babes mentioned in the title are referring to the magic numbers used in the Java Class File Format and the Java pack200 compression format. This article looks at the hex dumps of class file to look at the magic number as well as the class file major revision number.
While defining a file format, it is a common practice to have the file start with a specific byte sequence. This allows the programs or Operating System to recognize that file type. Think of it as a signature(initials) if you will. The magic number concept extends to various other things like IP addresses or message formats used in protocols.
The following list shows some interesting magic numbers. If you interpret these bytes in hexadecimal base you will notice some words and messages. Obviously, by looking at the following examples, you can tell that the software engineers who came up with these, have a great sense of humor.
The first four bytes of a Java .class file when interpreted as hexadecimal numbers are 0xCAFE 0xBABE. If you observe carefully these spell out the words Cafe Babe. As explained earlier, Java class file uses the byte sequence 0xCAFE 0x BABE as the magic number. Look at the following screenshot showing the hex-dump of a .class file. The black rectangle outlines the magic number.
Byte number 4 and 5 (first byte is being referred as byte 0) show the Java Class Minor Revision Number. In the above screenshot it is 0. This has been shown with a red border.
Byte number 6 and 7 (first byte is being referred as byte 0) show the Java Class Major Revision Number. This should be interpreted according to the following lookup table. In the above screen shot it is 0x32 which corresponds to J2SE 6.0. This has been shown with a green border.
J2SE 7 = 51 (0x33 hex),
J2SE 6.0 = 50 (0x32 hex),
J2SE 5.0 = 49 (0x31 hex),
JDK 1.4 = 48 (0x30 hex),
JDK 1.3 = 47 (0x2F hex),
JDK 1.2 = 46 (0x2E hex),
JDK 1.1 = 45 (0x2D hex).
The pack200 jar compression utility from Sun/Oracle uses 0xCAFE 0xD00D as the magic number. I highlighted the magic number in the following hexdump of a pack200 compressed file.
