Java ClassLoading

The essential part of the java world, but why is it so rigid and cumbersome?

Every time we start Java the class loader is the essential part that drives the startup process.
Every single piece of code that you have ever written for java is handled by some ClassLoader.
Because it's not that easy. When a developer can develop an application that effectively uses ClassLoaders, I consider that person to have advanced level of knowledge of Java.

ClassLoader is essential in defining a Class. Basically a class lives attached to a class loader. That is both a good and a bad thing.

• The main positive thing is that we can have multiple versions of the same class without conflicts
• The main negative thing(in current state) is that we need to remove the whole ClassLoader(with it's children) to reload our changes.

The basic fact is that these 2 points are not mutually exclusive.
But this way is mature. It's been with us for a very long time. We are actually used to it in it's current state.

That is where tools like ZeroTurnaround's JavaRebel comes in our view. The idea is nice, it's executed well, and it definitely shows that there is a need for it.

They use the new Instrumentation API.
Instrumentation API is great, but it does have a little problem: no schema changes are allowed.
That means that most of your changes will need the old process.

Is it time we had a new method in ClassLoader that would unload a class(ClassLoader.undefineClass)? Or reload it, at least?
I mean, the dynamic languages had that forever. PHP is a language that has a lot of inexperienced developers, and they still rarely manage to shoot themselves with that "feature". Does everyone consider everyone in java land an idiot that has to be constricted in every possible way?

Java(and Java EE) deployment lifecycle is criticized a lot. It's long. Very long. And the compile time is not the main factor here, it's the deployment itself. With the current need to trash the whole ClassLoader hierarchy we are definitely taking too much time and memory consumption(resource usage) does suffer.
Every single (re-)deploy goes through the same procedure on the lowest level:

• Application specific operations
• Remove any references to the ClassLoader(s) of the application
• Create a new ClassLoader
• Link the ClassLoader to the deployed code
• Application specific operations

And this is an example where I just added a new logging method and a few statements to a class! As you look at it you might think what a sad state we are in!
And if you have a thread there, guess you will have to restart the JVM to get rid of the old code from the memory.

Now, I am NOT an expert in JVM internals, but how hard is it to change the piece of data in memory? Java classes are just data in the memory, like everything else.

So what do you think? Is it time we have an ability to change the bytecode more dynamically?
To have the classes reloaded through ClassLoader? Or, at least, the Instrumentation API would have the restriction on schema changes removed?

What are your opinions?