In Sun's (Sparc Solaris 1.2) implementation of classloading from downloaded jar files, no entries can be examined until the jar directory is downloaded, which is at the very end of the jar file. The jar file is cached on disk and kept open until the virtual machine shuts down. It might be possible to fix some of these implementation issues, so that entries could be accessed once they have arrived, and the jar file would be deleted once the classloader than opened it was unreachable. But the archive would still have to be kept cached while classes were still being loaded, and classes would likely be copied in memory several times before being loaded.
An alternative approach would be eager class loading - to load classes into the JVM as soon as they arrive (i.e., invoke java.lang.Classloader.defineClass(...)), without buffering them or waiting for the entire archive to arrive. This allows us quicker access to some of the class files in the archive, and eliminates the need to cache or buffer a copy of the jar file.
If this resulted in loading many classes that were not needed, it might result in increased resource costs or performance problems. But this is already an issue for Java archive. If you are going to download a large archive over a network for direct execution, you already want to make sure that most of the classes will be actually used. Otherwise, you will pay the transmission costs for classfiles you won't use. There are several approaches to increasing the percentage of classfiles that are actually used. A tool such as JAX may be used to eliminate from third-party libraries classfiles that cannot be loaded by the application being distributed. Profiling [KCLZ98] could be used to determine a desirable order for classes. You could also break up packages into separate archives, and have rarely used classfiles loaded separately.
The eager class loading approach works with a standard jar archive, as well with the packed format. Note that before a class X can be loaded, the superclass of X and all interfaces implemented by X must be loaded. If the request to load X is done in a thread separate than the one which is handling the download and spawning of threads to load classes, the system won't deadlock, but it also won't be efficient. Instead, we should make sure that the superclass of X and the interfaces implemented by X appear in the archive before X.