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

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?

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.

If you run the command:

java -verbose

It will show you every class it loads in order to start the VM. If you add -verbose when you start a java program you will get a complete list of what that program needs to start. But this does not include any further classes it may need as it does it's work.

Why do you need to know what classes are needed?

IANAL, but you may risk being sued by Oracle if you strip down the java.* classes, because Sun/Oracle's public patent grant for JDK patents requires that you implement the full java.* interfaces, and that you do so compatibly with the standard. (I think this is part of what the Google suit hinges on.)

Aside from that, I think the Project Jigsaw developers are having a non-trivial time deciding what belongs in the base JDK install, and what belongs in a module. I recall reading a blog post (can't find it now) about some problems breaking circular dependancies between things that should be in modules (XML, IIRC) and the base install.

You are trying to pull apart a 7000 class application to see which ones are essential. If you did, there is no way you could guarentee the JVM would not fail at some random point in the future? Worse if it blew up for any reason, the finger is likely to be pointed at you first until you can prove it had nothing to do with removing the classes.

If you are using a mobile device and need to save capacity, I suggest you use the JME. However if you are using a desktop where 200 MB costs less than one penny, is it really worth the risk? If it blows up will it cost you more than a penny, I suspect it will.

An analogy, you are walking along a major road and you see what might be a penny on the other side. Do you cross the road through heavy traffic to get it? I suggest you just keep on walking.

EDIT: If you want a cut down version of Java you can try the embedded version. http://www.oracle.com/technetwork/java/embedded/downloads/index.html

It has a 32 MB and 70 MB variety.