Theoretical aspect of JVM programs : class files and internalization, and execution state

Question

I have been playing with development, testing, and deleting build directories lately - and noticed that this causes less errors than I would assume.

Im curious if anyone can offer up a detailed explanation of what happens when we delete a directory of class files while a java application is running. I assume that at some point, this would not effect the application (i.e. because all operations would have been pushed onto the stack as byte code).. But when would we reach this point-of-no-return ? Does the JVM, at some point, take cache or take full-ownership of all classes in a running application, so that their initial location (i.e. the location of .class files when we initially started running a java process) no longer matters ?

Peter Lawrey · Answer 1 · 2012-04-27T16:54:49.930

2

The class file is needed when it is first accessed. It i not usually cached, instead the ClassLoader extracts all the information it needs and doesn't read the .class again.

Usually the best practice is to write to a new directory, when creating a new version if the last version is still live (or if you want the ability to roll back to that version)

Deleting/editing a program while it is running causes problems for shell scripts and C programs, so its shouldn't be too surprising it doesn't work so well in Java.

As @Louis Wasserman points out, the OP states it works better than expected. IMHO that would depend on the application. If all the classes needed are loaded, you can delete them all. An application which loads classes long after it has started, wouldn't behave this way.

edited Apr 27 '12 at 16:54

answered Apr 27 '12 at 16:42

Peter Lawrey

525,659
79
751
1,130

Mention trace classloading to reproduce the problem deterministically. – Amir Afghani Apr 27 '12 at 16:44
1

I think the OP was saying that deleting a program while it's running works _better_ in Java than he expected. – Louis Wasserman Apr 27 '12 at 16:47
Right - and if he turned on trace, he could confirm or falsify such a claim. – Amir Afghani Apr 27 '12 at 16:49

score 1 · Answer 2 · edited May 23 '17 at 12:28

Most JVMs today load classes in an "on demand" fashion, so when you start the Java program, the JVM reads in .class files as needed based on active references. (It's more complicated than that, but for simplicity, assume that approximates reality.) Once loaded, the bytes on disk are no longer required as they've been translated into the JVM-internal representation and are held in memory. Effectively, once the classes are loaded there's no need for them on disk any more (assuming you'll never run that same exact program from scratch again!).

However, there's a big wrinkle... it's likely not all the classes from the program are actually loaded in an average run. Imagine an error class that is only needed in odd circumstances. Normal execution won't load it, so if you were to simply delete everything from the file system once the program was running "normally" and later hit the error condition which required the class to be loaded, the JVM would fail in a double-bad way - rather than throwing the expected exception (that would be handled normally via your catch blocks) a more serious error would happen, derailing your logic.

It is possible to "preload" all classes, but it's a bit of a hack, and normally accomplished with kludges like keeping a list of all classes in your app and doing a "Class.forName()" for each one. See this SO article for how people do it for performance reasons.

Theoretical aspect of JVM programs : class files and internalization, and execution state

2 Answers2