A story of him who wanted to not call the constructor !

Hello there, everybody !
Welcome to my blog. Please seat yourself and enjoy the post.

Once upon time, a old wise man was sitting alone thinking in some problem that was taking all over his mind. He wanted to make things easier for the local programmers who use the RMI library. There problem was that to use RMI you need to override and implement certain interfaces. So the poor villagers, er, programmers had to work extra hours to harvest, er, design the changed system to adapt it to RMI specs.

The old wise man have figured out a simple way to help them. He can provide them with a magical bean, er, program that can do the tedious specs conformation for them. The magical bean overrides the classes and sends the overridden class over the network, instead of an evil magical creature, er, RMI artificial stub that throws them with rocks, er, RemoteExceptions.

The old wise man spent days and days working alone all the day long, until he finally produced what he have promised. The magical bean worked as expected. However, there were one drawback with that bean. It kills the other crops, er, remote stubs still call the default constructor of the super class. That constructor is meant to run on the server side. In some cases it can wreak havok if run on the client side; creating or deleting other crops, er, files for example.

That problem kept the old wise man up for 3 days. although it was the big feast, but he cared for the poor villagers more than his own joy. He set his mule up, and started on his way to search for a solution. Even if it took him to sweep the entire globe.

On his mysterious journey, he met a powerful wizard, called BCEL. BCEL claimed that he has a potion that enables the old wise man to control the magical bean to an unprecedented level. The old wise man believed him and bought the recipe. He spent the next weeks trying to prepare the potion. The results wasn't encouraging at the first, but as he got better in preparing it over time, the results got better.

Trial #1
Now it is the big day. He have gained enough skill to try to prevent that evil magical bean from invoking the constructor. He have manipulated the magical bean and removed the invoke that calls the super constructor. But the soil, er, JVM, struck him with lighting, er, exception that the object is uninitialized.

Trial #2
Bravely standing up after the lighting, he manipulated the magical bean again, to call the Object's constructor directly, without passing the on the original super constructor first. But still, JVM struck him again saying that the wrong constructor is being called!

Trial #3
He thought, if I can manipulate the magical bean's constructor, why don't I manipulate it's super constructor too ? And the next super one and so on. So staying for hours in his laboratory, he invented his own fertilizer, er, class loader. That special fertilizer has the ability to manipulate every magical bean, and even every normal bean that gets out of the soil. Yet he wasn't so lucky. JVM had to make his grow the magical bean twice every time he wanted harvest an RMI application.

The old wise man keeps trying, and hopefully soon he will be able to something. Even if he had to manipulate JVM itself!!

End of part 1...

Update 22/dec/2007: Using JVMTI (JVM Tool Interface) One could change every loaded class in the system. It can also redefine them as many times as he want to. And best of all, it needn't be native code ;).