LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   Will changes in Java binary executable affect running Java programs? (http://www.linuxquestions.org/questions/programming-9/will-changes-in-java-binary-executable-affect-running-java-programs-873900/)

xuancong 04-08-2011 11:16 PM

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

Heraton 04-10-2011 06:43 AM

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

paulsm4 04-10-2011 01:47 PM

Quote:

Q: java virtual machine loads all dependent class binaries before executing the program?
A: No, not necessarily. Java can (and does) freely load classes as needed at runtime. The Java runtime is dynamic.

Quote:

Q: Take note that my code does not invoke explicit class loader... And those parts that are changed and recompiled are dependent files at compile time.
A: If it's a small enough program, it's likely that Java *will* load everything it needs at startup.


Quote:

this shouldn't be too hard to test. Why don't you write some simple class... start a program calling that class ... and then try to replace the class with some new class (returning "new" instead).
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

xuancong 04-12-2011 04:31 AM

Quote:

Originally Posted by Heraton (Post 4319856)
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.

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

Heraton 04-13-2011 12:37 PM

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

xuancong 04-14-2011 12:43 AM

Quote:

Originally Posted by Heraton (Post 4323568)
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-:)

paulsm4 04-14-2011 01:04 AM

Quote:

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.
Of COURSE that's inefficient. Of course Java doesn't do this.

Quote:

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.
"Delayed loading" is a Good Thing :)

Quote:

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.
If you believe this means that no Java program will ever load a class file once it's finished initializing - then you're mistaken ;)


All times are GMT -5. The time now is 03:18 AM.