Why doesn't the JVM load classes from a databa

Question

Why doesn't the Java virtual machine load classes from a database (similar to the GAC of .NET)? As I understand it, currently it has to read and scan the manifests of each JAR on the class path in order to locate class files. Wouldn't using a database (like SQLite) boost startup time?

Answer 1

You can create an index jar which will tell the runtime which class is in which jar. To do this you take your applications main jar and ensure the Class-Path attribute is properly set in the Manifest. You then run "jar -i MyMainJar.jar" to create the index.

If you don't have a main jar, you can create one that just contains a Manifest with the Class-Path attribute set and index that. If you load this jar first, the ClassLoader will use the index and find classes more quickly.

Answer 2

It doen't because no one added that to the standard libraries. Also for bootstrapping purposes (e.g. loading the JDBC driver for the DB access), the existing mechanisms would still need to be present.

It is not too hard though to create a classloader that talks to a database to retrieve the class bits.

Answer 3

You could use a nexus server as a maven repository for libraries and load them into an OSGi container. This allows you to build/deploy/load/unload whole libraries without touching the jars or classes directly. However, it places local copies of libraries on disk for performance and doesn't allow you to manage individual classes.

I would find it hard to believe that loading clases over a socket connection is faster than loading compressed files directly off disk. (as maven/OSGi does) esp. once the file are in cache. Most of the time spent in loading the classes is in the code executed in static blocks and later in compiling the code, neither of which a database would help you with.

I would be interested in seeing a performance comparison. How do database class repositories handle versions? How easy/reliable is it to roll back a version of library for example or group of class with interdependancies?

Answer 4

Your fundamental point is valid: there are optimisation possibilities in Java classloading, and there's clearly a lot of duplicated work in finding classes, especially those that are used frequently. The JVM vendors have actually done quite a bit of work in this area already. See Oracle's shared data description for an example.

I speculate that the overheads and complexities of using a database are overkill for what is effectively a simple caching and indexing problem.

Answer 5

Depending on how you define "database" both IBM (shared classes) and Oracle (shared data) already do have technologies to speed up startup and decrease memory footprint.

Class load time is actually very small (on a class by class basis), so adding something like a database in the way won't realistically change you performance in a good way, especially if you have to blast the bytes over a wire (rather than simply read a local file system jar entry). All the JVMs today are highly optimized down the class loading path and adding SQL will certainly not help for performance. (flexibility of distributed repositories, etc.. is a different question and I see advantages there.)

Answer 6

There's very active work going on to boost startup time (it's one of the goals for Project Jigsaw, which forms part of JDK 8).

But the optimizations aren't as straightforward as just "dump the classfiles in a DB". There are several concerns here, some of them competing.

And the GAC has its own problems, none of which I think we'd want to replicate...