Month: December 2011

Not sure if anyone of you has tried opening a java .class file using some hex editor. If you haven’t yet, try it once!

The first thing that you will notice on doing so, is it’s very first 4 byte header “CAFE BABE” 😉

Every java class files are identified by 4 byte header (in hex) CA FE BA BE (first 4 entries). This signature is just an easy way of verifying that a block of data really does claim to be an instance of the Java class format. Every Java binary class, even one that isn’t present on the file system, needs to start with these four bytes.

The history of this magic number was explained by James Gosling:-

“We used to go to lunch at a place called St Michael’s Alley. According to local legend, in the deep dark past, the Grateful Dead used to perform there before they made it big. It was a pretty funky place that was definitely a Grateful Dead Kinda Place. When Jerry died, they even put up a little Buddhist-esque shrine. When we used to go there, we referred to the place as Cafe Dead. Somewhere along the line it was noticed that this was a HEX number. I was re-vamping some file format code and needed a couple of magic numbers: one for the persistent object file, and one for classes. I used CAFEDEAD for the object file format, and in grepping for 4 character hex words that fit after “CAFE” (it seemed to be a good theme) I hit on BABE and decided to use it. At that time, it didn’t seem terribly important or destined to go anywhere but the trash-can of history. So CAFEBABE became the class file format, and CAFEDEAD was the persistent object format. But the persistent object facility went away, and along with it went the use of CAFEDEAD – it was eventually replaced by RMI.”

Issue: 

Think of a situation where your java application wants to change the owner & permission of a unix file programmatically. With JRE1.5, the obvious way to achieve this could be the usage of Runtime.exec.  With Unix as runtime, this invokes fork() which makes a complete copy of entire parent process’s address space and exec() then turns that copy to a new process. The disadvantage of this approach is that you will end up with Out Of Memory issues without a good reason.

Solution:

Use Java Native Access to invoke native C POSSIX library!

JNA allows you to call directly into native functions using natural Java method invocation. The Java call looks just like it does in native code. The JNA library uses a small native library stub to dynamically invoke native code. The developer uses a Java interface to describe functions and structures in the target native library. This makes it quite easy to take advantage of native platform features without incurring the high overhead of configuring and building JNI code for multiple platforms.

Below is a java code snippet which changes owner and permission of a unix file without using Runtime.exec. You need to place jna.jar and platform.jar in your classpath for compiling and running this application :-

import com.sun.jna.Library;
import com.sun.jna.Native;

public class FilePermOwnerChange {
public interface POSIX extends Library {
public int chmod(String filename, int mode);
public int chown(String filename, int userId, int groupId);
}

  public static void main(String[] args) {
       POSIX posix = (POSIX) Native.loadLibrary("c", POSIX.class);
       posix.chmod("/tmp/BufCre.txt", 0664); //0664 is just an example
       posix.chown("/tmp/BufCre.txt", 1000, 1000); // 1000 is just an example. Give the UID and GID respectively for the new owner of this file.
  }
}