Which classes are absolutely necessary to get a Java VM running?

Question

What is the smallest subset of classes with which a Java VM is able to start up?

I guess things like Object, String and the primitves are absolutely required because they are hard-wired in many parts of the VM.

I'm interested in how big the dependencies between the JVM and the JDK are.

The basic question I'm wondering about is:

If I would decide to distribute a JVM with a different programming language and different standard libraries, how much of the "Java" classes do I have to carry around to make the JVM happy?

Answer 1

The best way to find out is to try it and see; e.g. use java -verbose. to run the minimal program in a variety of JVM hosted languages.

But the answer is likely to be:

• JVM version specific, and
• programming language specific.

I should also point out that the answer(s) you get won't be of any practical use (... unless you plan to create a cut-down JRE. And if that is the case, read the followup below.)

Do you know if all of the classes are strictly necessary or does the VM also preload classes which it expects to be used in all cases by applications?

The JVM does not preload things on that basis. Rather, it loads the dependency closure of that your code staticly depends on. Depending on what classes your application uses, this may result in classes being loaded that aren't actually used. The Sun engineers have done a lot of work to try and reduce this effect over the years, but it doubtless still happens to some extent.

FOLLOW UP

Reading between the lines, it seems that the intent is to create a cut-down JVM package to support the runtime requirements of some other language. If so, consider these points:

• There are licensing requirements on what you can do with Java vis-a-vis the creation of cut-down versions. Specifically, Java, JVM and JRE are trademarked terms, and Oracle could come after you if you use them in the context of a cut-down JRE. (I'm not saying you cannot do it, but you do need to check the legal aspects for yourself.)

• There are definitely support issues. For instance, you need to track any relevant Java / JVM security issues and patches and create new versions of your base platform as reuired.

• If you intend to provide any way for application programs in your new language to call Java libraries, then using a cut-down JRE could be a serious pain in the backside for some users. Especially if you package your stuff in a way that means they have to use your cut-down JRE.

• There are tools in a JRE / JDK that could be useful to you / your users. Tools like profilers, debuggers, the JAR command, and so on. Your JRE would need to include all classes needed to run them.

Finally, a 100Mb download is not a significant issue for the VAST MAJORITY of users. And if it is, you could make a bit of money to support your project by selling installer DVDs.

Focus on whatever it is you are really trying to do here ... and leave the installer optimization to when you've got a something of production quality to optimize.