Will changes in Java binary executable affect running Java programs?
 

Hi,

I'm using Windows and Linux/Ubuntu. I want to know whether java virtual machine loads all dependent class binaries before executing the program. And if I changed the Java code and recompiled to form new class files, will it affect the outdated copy of the same Java program that are already running?
Take note that my code does not invoke explicit class loader (things analogous to Wind32 function LoadLibrary("???.dll")). And those parts that are changed and recompiled are dependent files at compile time.

And does this behaviour OS dependent? Thanks!

Xuancong

It's been a while since i last used Java, but if i did not misread your question, this shouldn't be too hard to test. Why don't you write some simple class with a certain behavior (always returns "old", when a certain function is called for example), start a program calling that class and then try to replace the class with some new class (returning "new" instead). If the class is replaced successfully, the answer should change, otherwise it shouldn't.

regards, Heraton

A: No, not necessarily. Java can (and does) freely load classes as needed at runtime. The Java runtime is dynamic.

A: If it's a small enough program, it's likely that Java *will* load everything it needs at startup.


Good advice. Under most circumstances, you probably WON'T load the new version of the class.

Better advice: don't rely on this kind of behavior in a production program.

Here's a great, short article on the subject:

http://onjava.com/pub/a/onjava/2005/...ssloading.html

'Hope that helps .. PSM

PS:
There isn't just one class loader: there's actually a hierarchy. Another good link:
http://onjava.com/pub/a/onjava/2003/...assloader.html

No. Not as easy as you think. Loading the actual .class byte-code file upon object instantiation (i.e. new ObjectClass(...)) is very inefficient. Imagine: everytime as you new something(...), JVM starts to load something.class from the disk. OMG: it'll jam your disk IO and make execution cumbersome. Therefore, any JVM implementor with IQ>0 will not do this.
So what I'm worried is that in windows, there's something called delayed loading: the .dll is loaded when the actual code/data is accessed. If the same thing happens to Java, testing a small piece of code may not imply the same conclusion on a very complex bundle of code involving thousands of classes (my case).

Thanks to http://java.sun.com/docs/books/jls/s...doc.html#47907
This means, as long as my Java code doesn't call LoadClass to dynamically load a class at runtime, once things gets running, .class files are free to change. Before codes gets started running, it's linked; before it's linked, it must be loaded which reads the .class bytecode file.

Xuancong

Well, now i am sure i misread your question. I somehow expected the question to be more general, and therefor didn't realize you where looking for the details.

It's just curiosity, but i wonder what application needs to change the dependent classes at runtime? I can find only one reason: Tricking the JVM into running selfmodifying code...

regards, Heraton

To honest, I'm a postgrad doing machine learning. I have several small ways of modifying the algorithm and just want to test whether it works. The experiment takes long time to run and duplicating the whole package for each small modification is clumsy. I just want some short cut-:)

Of COURSE that's inefficient. Of course Java doesn't do this.

"Delayed loading" is a Good Thing :)

If you believe this means that no Java program will ever load a class file once it's finished initializing - then you're mistaken ;)