Archive for the 'Java' Category

__LINE__ __FILE__ macro for java. Part II.

Second part of this post

How does it work?

As the jvm loads each class, it passes it to each instrumentation which registers a ClassFileTransformers. This gives a chance to alter its byte code. I am using this system to remove the reference to the __LINE__ field, and change it with the current line.
Let’s see the byte code of a simple class, to see how we can manipulate it

System.err.println( __FILE_LINE__ );

This simple code is compiled to the following bytecode.

   0:   getstatic       #8; //Field java/lang/System.err:Ljava/io/PrintStream;
   3:   getstatic       #14; //Field com/dg/ab/use/instument/CodeLocation.__FILE
   6:   invokevirtual   #20; //Method java/io/PrintStream.println:(Ljava/lang/String;)V 

This can be easily generated using javap –c, which is included in any jdk

At line 3, we can see the actual instruction, which is loading the content of the __FILE__ into the stack. At this point, if you can just change this instruction to load a string which contains the actual line position, we solve our problem.
So we expect to convert the previous bytecode into this one

   0:   getstatic       #8; //Field java/lang/System.err:Ljava/io/PrintStream;
   3:   ldc     #14; //String
   5:   invokevirtual   #16; //Method java/io/PrintStream.println:(Ljava/lang/St

And doing that is extremely easy using the ASM bytecode manipulation library.
We just have to load the class, and ask a ClassReader to process it.
During the process, the ClassReader will produce some visiting events, that will be passed to our ClassAdator which will slightly change the content, and pass the event to a ClassWriter that will write the visiting event to bytecode.

To come


public class CodeLocationClassTransformer  implements ClassFileTransformer {
	public byte[] transform(ClassLoader loader, String className, Class redefiningClass, ProtectionDomain domain, byte[] bytes) throws IllegalClassFormatException {
		System.out.println("CodeLocation to Transform Class: " + className);
		ClassReader cr = new ClassReader(bytes);
		ClassWriter cw = new ClassWriter(cr, 0);
		CodeLocationClassAdapter adapter = new CodeLocationClassAdapter(cw);
		cr.accept(adapter, 0);
	    byte[] result = cw.toByteArray();
		return result;

	public class CodeLocationClassAdapter extends ClassAdapter {
		private String source;
		public CodeLocationClassAdapter(ClassVisitor cv) {
		public void visitSource(String source, String debug) {
			this.source = source;
			cv.visitSource(source, debug);

		public MethodVisitor visitMethod(int access, String name, String desc,
				String signature, String[] exceptions) {
			MethodVisitor mv;
			mv = cv.visitMethod(access, name, desc, signature, exceptions);
			if (mv != null) {
				mv = new CodeLocationMethodAdapter(this, mv);
			return mv;

	public class CodeLocationMethodAdapter extends MethodAdapter {
		private Integer lineSeen;
		private CodeLocationClassAdapter owner;
		public CodeLocationMethodAdapter(CodeLocationClassAdapter owner, MethodVisitor mv) {
			this.owner = owner;

		public void visitFieldInsn(int opcode, String owner, String name, String desc) {
			if ( opcode == Opcodes.GETSTATIC ) {
				// replace the instruction 
				// getstatic       #23; //Field com/dg/ab/use/instument/CodeLocation.__FILE_LINE__:Ljava/lang/String;
				if ( owner.equals(CodeLocation.class.getName().replace(".", "/"))) {
					if ( name.equals("__LINE__" ) ) {
						// by
						// ldc #xx // "linenumber"
					} else 
					if ( name.equals("__FILE__" ) ) {
						// replace with a ldc
						// ldc #xx // "source file"
					} else 
					if ( name.equals("__FILE_LINE__" ) ) {
						// replace with a ldc
						// ldc #xx // "source file:linenumber"
						super.visitLdcInsn(this.owner.source + ":" + String.valueOf(lineSeen));

			super.visitFieldInsn(opcode, owner, name, desc);
        public void visitLineNumber(int line, Label paramLabel) {
        	this.lineSeen = line; 
        	super.visitLineNumber( line, paramLabel );


As you can see there are 3 main steps used during the byte code manipulation.

  • CodeLocationClassTransformer

    Class call by the jvm, in order to instument the classes. Transform the class by processing the bytecode through a CodeLocationClassAdapter
  • CodeLocationClassAdapter

    Will That store the current filename and process the Method bytecode through a CodeLocationMethodAdaptor.
  • CodeLocationMethodAdapter

    store the current line information, as provided by the ASM library. And convert during the visiting instruction events, the GETSTATIC on our fields ( __LINE__, __FILE__ ) to the LDC instruction with the appropriate parameters.

The only thing which is still missing is the code to register the CodeLocationClassTransformer.
This is done in the class PremainCodeLocaiton

public class PremainCodeLocation {
	public static void premain(String agentArguments, Instrumentation instrumentation) {	
		instrumentation.addTransformer(new CodeLocationClassTransformer());

The agent premain class is called whe the agent jar is provided in the command line of the java, and this jar contains the appropriate entry in the manifest.

Manifest-Version: 1.0 
Premain-Class: com.dg.ab.use.instument.PremainCodeLocation

RMI, JDK 1.6, OSGi ( 1 of 2 )


If you ever wanted to search for some information about Rmi, you probably founds the sun tutorial which is located here :

This tutorial is really complete, but it has been there for years now. And since then, some big improvements have been done on the rmi support of java. For example since 1.5 you do not have to create the stub or the skeleton class.

Due to that, I believe that there are easier ways to implement a RMI service now, and that is what I will try to show you in this article.

While preparing this small article, I digged a little bit on google. It seems that a lot of users have problems or at least had problems in the past, especially because the codebase classloading messes.
It is required to put your jars on a webserver, set a security manager, and set some system properties to find back the published jars, and only then the magic of rmi class loading will occur.
But does this fit on an osgi architecture, where each application has its own well defined dependency context, defined using a declarative way. And does the service support interface versionning ?
Basically no, especially for the interface versionning !

In this article, I will try to show you my way of implementing rmi application, in a OSGi environment. IMHO using the easier way, or at least a less messy way.

Writting the SimpleRmiServer

While trying to be as simple as I can, I will try to show you how to write a RMI Service that will use most of the main features of RMI :

  • Publishing a RMI interface
  • Sending custom object and receiving it back
  • And even show you how to implement a service callback

Design the remote interfaces

Sources : The svn repository is

The remote interface of my test service is really simple. It simply contains 2 methods

  • The first one is used to execute some codes on the server synchronously
  • The second method allows you to post a request, and to be called when the result is ready

public interface ISimpleRmiService extends Remote {
  public static final String BIND_NAME = "ISimpleRmiService";
  public Response request(Request request) throws RemoteException;
  public void asynchronousRequest(ICallback callback, Request request) throws RemoteException;

Remember that any RMI interface needs to follow some rules !

  • The interface must extend the interface java.rmi.Remote
  • Any methods of this interface must throw java.rmi.RemoteException
  • Any parameters of this interface must be serialisable
  • Any callback interface must follow these rules as well
  • And as a personal rule, I also add the binding name as a static field, and prefix the interface name with I

This is it ! As you can see the interface is composed of two methods

Let’s now design the callback interface using the same rules

public interface ICallback extends Remote {
  public void response( Response response ) throws RemoteException;

And the parameter object, request and response are basically a Serializable bean which is holding a string value.

public class Request implements Serializable {
  private static final long serialVersionUID = 1L;
  private String value;
  public Request( String value ) {
    this.value = value;
  public String setValue() {
    return value;

Then all these interfaces are putted in a single OSGi bundle, which is going to be shared between the client and server.

Implementing the remote server

Sources : The svn repository is

The code of the remote service does 3 things.

Create the RMI Registry

The rmiregistry is a special component in the RMI architecture used to expose the published service.
The normal way of starting it, is to run the rmiregistry command. But personally I do not really like having to manually start the rmiregistry by hand. It is basically another process to monitor in the system, and even more, if for any reason the rmiregistry is restarted, every RMI server needs to be exported again!
But since the JDK 1.1, it is possible to start the rmiregistry using a simple call to LocateRegistry.createRegistry
I believe that this way of handling the rmiregisty is better most of the time, it is tying your rmi server with the rmiresitry within the same jvm. At least when you start your rmi server, the rmigistry starts automatically!
Also, having the rmiregistry and the rmi service inside the same jvm allows you to bypass some of the class loader messes of rmi.

Implementing the service class

The rmi service class is really easy to implement, it is a simple class implementing the remote interface, and extending UnicastRemoteObject.

public class SimpleRmiService extends UnicastRemoteObject implements ISimpleRmiService {
  public Response request(Request request) {
    Response response = new Response( "Response @ " + request.getValue());
    return response;

  public void asynchronousRequest(final ICallback callback, final Request request) throws RemoteException {
    executor.execute( new Runnable() {
      public void run() {
        try {
          Response response = new Response( "Response @ " + request.getValue() );
        } catch ( Exception ex ) {

And to publish it, simply register it with the remote registry previously created during the first step

Binding the Rmi service class

You can instantiate the rmi service class, and publish it to the rmiregistry.

One good place to start the rmi registry and to bind the rmi service is the Bundle Activator class of your bundle. In the start method of the bundle activator, simply do :

Registry registry = LocateRegistry.createRegistry( Registry.REGISTRY_PORT );
registry.bind( ISimpleRmiService.BIND_NAME, new SimpleRmiService());

To try the server part of this application, simply start your favourite osgi framework, and install the interface bundle and the service bundle. Or just right click on the “SimpleRmiServer.launch” file and run it.

Implementing the remote client

Sources : The svn repository is

Implementing the client is even easier.

  • You just need to first connect on the rmi registry
  • Lookup the rmi service using the binding name
  • Call the method

Registry registry = LocateRegistry.getRegistry( Registry.REGISTRY_PORT );
ISimpleRmiService simpleRmiService = (ISimpleRmiService)registry.lookup( ISimpleRmiService.BIND_NAME );
Response response = simpleRmiService.request( request );

But what about the callback implementation ?

It is almost the same method as for the ‘direct’ call, you just need to provide a correct ICallback implementation.
The ICallback implementation is just another rmi service binded anonymously, therefor it needs to behave appropriately as a remote object.
As for the main service, the best way to achieve this is to extend the UnicastRemoteObject.

public class Callback extends UnicastRemoteObject implements ICallback {
  private static final long serialVersionUID = 1L;
  public Callback() throws RemoteException {
  public void response( Response response ) {
    System.out.println("Response received: "+response);
    System.out.println("Response : "+response.getClass().getClassLoader());

To test it, just run the run configuration named ‘SimpleRmiClient.launch’


As you can see, it is working. No need to create the stub using the rmic tools, no need to start the rmi registry, and you do not need to publish the jar interface on a webserver.

However this solution is too light for a real life example.

  • You cannot have multiple rmi services, since the registry is started with the SimpleRmiServer
  • Restarting the SimpleRmiServer will fail, when the registry is rebinded

These problems will be solved in my next article, and I will even try to show you how to publish different versions of the same interface !